Mathias,

I'd like to asking how the sensors will be emulated in cupcake
emulator as the sensors_trout.c and sensors_stub.c are gone in
cupcake.

- Vettey

On 1月10日, 上午6时35分, Mathias Agopian <[email protected]> wrote:
> On Fri, Jan 9, 2009 at 1:26 AM, pramod gurav <[email protected]> wrote:
>
> > On Fri, Jan 9, 2009 at 12:56 PM, Mathias Agopian
> > <[email protected]> wrote:
>
> >> Hi,
>
> >> Android doesn't "require" yaw / pitch / roll per se. In theory, well
> >> written applications should check for the presence of these sensors.
> >> Unfortunately, in Android 1.0 there wasn't an easy way to integrate a
> >> newsensorh/w.
>
> >> I think it is more sane to target the "cupcake" release of Android,
> >> which a work in progress is available in the main git repository.
>
> >> Future (cupcake) applications will be able to  use the SensorManager
> >> to calculate the yaw / pitch / roll from the acceleration and magnetic
> >> data (this is actually more precise than the data coming out of the
> >> driver!). Additionnaly, there is a HAL module to implement yoursensor
> >> h/w which describes precisely what is expected from the higher layers
> >> (see sensors.h).
>
> >> Asensorh/w can expose yaw/pitch/roll if it wants to, but is not
> >> technically required; the framework will expose a "fake"
> >> yaw/pitch/roll sensors if one is not published by thesensorHAL and
> >> if Acceleration and Magnetic data are available.
>
> > Does this mean I can remove the sensors from SUPPORTED_SENSORS
> > in hardware/libhardware/sensors/senors_trout.c if they are not supported?
> > For example my h/w gives only magnetic (compass) and accelerometer
> > axis values, so I will enable those in macro.
>
> You should not be using sensors_trout.c any more. This file is gone in
> cupcake. I think you didn't sync to the most recent git repository.
> We're not really supporting new sensors h/w in Android 1.0.
>
> Mathias
>
> >> Note that the definition of the axis at the h/w level have changed
> >> between 1.0 and cupcake, so be sure to read carefully the
> >> documentation in sensors.h.
>
> >> Android doesn't do ANY calibration on its own. The drivers and/or HAL
> >> modules are expected to do this.
>
> > So h/w does not support this, its my driver who will calibrate.
>
> >> In "theory", all you need to do is implement asensorHAL module
> >> properly (as documented in sensors.h. pay extreme attention to the
> >> definition of the axis and units). Unfortunately, in the current git
> >> repository there are no sample code of asensorHAL module, which
> >> makes this task more difficult; however we will fix this problem soon
> >> by including the G1 HAL module source code, stay tuned.
>
> > But i see some HAL source under hardware/libhardware/sensors/
> > I am making changes to one of these and using.
>
> >> I hope this helps.
>
> > Thanks for the quick reply.
>
> >> Mathias
>
> >> On Thu, Jan 8, 2009 at 9:45 PM, pramod gurav <[email protected]> wrote:
>
> >>> Hi All,
> >>> I am trying to integrate my compass and accelerometer sensors into 
> >>> android.
> >>> These are two different sensors which support only providing magnetic
> >>> x, y, z and
> >>> acceleration in x, y and z direction. As I gone through the HAL layer
> >>> of android I
> >>> could know that android expects yaw, pitch, row also from the under
> >>> lying driver.
> >>> I just wanted to conform this as the sensors we are using does not
> >>> give any values
> >>> other than above mentioned.
> >>> I would also like to know whether android does any calibration on its
> >>> own to get these
> >>> values in case these are not supported by hardware.
> >>> Please let me know if I need to provide more details regarding my sensors.
>
> >>> --
> >>> Best Regards
> >>> Pramod
>
> > --
> > Best Regards
> > Pramod
>
>
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to