Accellerometer ioctl

Andy Green andy at openmoko.com
Mon Mar 10 16:48:26 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Hi Andy,
> 
> do you have any sample code wrt. the LIS ioctl interface you did?

Hi Mickey -

You don't need any ioctls... they do exist on the /dev/input/event[2|3]
nodes but they are like info about what kind of data comes from the
device nodes rather than anything useful.

Just open a handle on /dev/input/event2 for example and parse the 16
byte packets coming back: you will block when there is nothing, but as
soon as you open it and until you close it, you should get 100 x 3
samples per second, one for X, Y and Z.

Here is the commit message I wrote for the patch that got them working.

''This patch removes the workqueue method originally implemented for
motion sensor service and replaces with with a platform-defined
callback which is used in the ISR.

An implementation for the callback is also provided which performs
IRQ-safe SPI bitbang at high speed to service the motion sensor
and insert the x y z data into the input queue.

Interrupts are changed to edge trigger from level removing the
sluggish behaviour.

Interrupts are serviced in typ 75 - 100us without involving the
scheduler now.

The input event interface was broken, this also fixes it.

# cat /proc/bus/input/devices
...
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="lis302-1 (top)"
P: Phys=
S: Sysfs=/devices/virtual/input/input2
U: Uniq=
H: Handlers=event2
B: EV=5
B: REL=7

I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="lis302-2 (bottom)"
P: Phys=
S: Sysfs=/devices/virtual/input/input3
U: Uniq=
H: Handlers=event3
B: EV=5
B: REL=7

Data is scaled to be report in mG, so 1000 = 1G.

Data should be reported at 100 sps per axis.
You can sample the X Y Z data easily through hexdump.
Hexdump on a serial terminal can't keep up with the
data, so it is not shown in order.

# hexdump /dev/input/event2
...
00009c0 55d7 478e 70bd 000d 0002 0000 ffdc ffff
00009d0 55d7 478e 712d 000d 0002 0002 03de 0000
00009e0 55d7 478e 714b 000d 0000 0000 0000 0000
00009f0 55d7 478e 976b 000d 0002 0000 ffee ffff
0000a00 55d7 478e 97c9 000d 0002 0001 0012 0000
0000a10 55d7 478e 97f2 000d 0002 0002 03de 0000
0000a20 55d7 478e 980f 000d 0000 0000 0000 0000

The first 8 bytes are timestamp info.
The next 16-bit word is EV_REL to show it is relative
coordinate data.
The next word is 0000=X, 0001=Y, 0002=Z
The last 32 bits on each line is the sample data, in
signed milli-G.

You can single out just one coordinate for rough testing
like this

# hexdump /dev/input/event3 | grep ".* .* .* .* .* 0002 0002 .* .*$" |
cut -d' ' -f8
03a8
03ba
03a8
03a8
03ba
03a8
03a8
03a8
03ba
...

Due to tolerances 1G is reported as ~0x3ba milli-G == 954mG
on the sensor I looked at.  Or it could be the alien space
drive I mounted on my roof.''

If you hit trouble or have questions please don't hesitate.  If you
think the driver should do some manipulation on the data first to cut
the report rate to userspace, that's really interesting too.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH1VhKOjLpvpq7dMoRArbaAKCF3d6YjeHWS2LQ1Sj5aoOgPtftogCfclx0
DNrOyyAHyLUh3i2XGSP+Hcw=
=pkkn
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list