Motion Sensor Status
andy at openmoko.com
Thu Jan 24 16:35:47 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
Hi folks -
Here is an update:
- The hardware seems to be okay as it is unless we see that I2C
corruption thing soon :-)
- Software is basically working but there is an apparent software bug
with the interrupt action right now which makes the machine very slow
due to excessive SPI activity.
I sent the patches out anyway due to the interest in the problem.
They're also in the kernel git tree at http://git.openmoko.org.
> - INT1 and INT2 signals on the LIS302DL really don't seem to act as the
> datasheet states: nobody has ever seen those pins either stop driving
> low or drive high even though we definitely follow the rules as
> described. Tying them together as they are shouldn't make a problem.
> We need to contact ST FAE and ask them to explain the behaviour.
INT1 and INT2 work fine now at least with a "golden" register init. I
think the actual problem was due to broken SPI bitbang only talking to
one motion sensor, by bad luck it was the one with the least accessible
INT pins. So I think we have been staring at the non-initialized
device. The other problem is that the CS signal is inaccessible on the
Anyway INT is working as an INT pin now.
> - I found the bitbang / platform code still only chooses one chip
> select all the time, I got too tired to fix it today, it can be fixed
> one way or another
This is resolved with patch 1/3 I sent -- we are talking properly to
> - The bitbang code even in the cutting-edge git kernels we are using
> does not seem to allow to change the synthetic clock rate for bitbang
> SPI, it seems to be fixed at 5us / clock despite the LIS302DL can handle
> 50 x faster and we just waste time and power spinning. Again we can fix
> it one way or another.
> - Due to the above right now a sample from one sensor is ~1.5ms and is
> done every 10ms (= 100Hz)... pretty insane but it can be reduced down to
> ~1/10th of that by speeding the bitbang clock as above. Still noticeable.
This is a bit more complicated. First the bitbang SPI clock is at 3us
period at the moment despite I asked for 100ns.
Once I had the INT pin working I hooked a scope probe on it so I could
watch it. I saw the latency from assertion to deassertion after
servicing was hugely variable, >=1.5ms but sometimes 50ms or more and in
granular lumps rather than completely random. This is caused by having
a scheduled handler take care of the SPI action after the interrupt, and
that is caused by the Linux SPI API apparently not working in interrupt
I think this will improve when the excessive SPI bug is fixed, but it
still might not be very good to add 200 actions/sec through the scheduler.
Right now because the scheduling can exceed a 10ms latency, it means it
can miss interrupts easily. That in turn meant that trying to use edge
triggered interrupts to fix the slowness bug only works for a little
while and then since it missed an edge stops generating interrupts.
> - Raw data for X Y Z looks good from the one chip I can really talk to
> right now: it seems consistent and responds well to changing the
> attitude of the device
Both sensors give different and consistent results without any obvious
corruption on a casual examination over a few minutes.
If you want to look closer apply the patch and uncomment the printk on
line 283 on ./drivers/input/misc/lis302dl.c - you'll get a console spew
with X Y Z from the two sensors, the pointer at the start lets you tell
them apart relatively anyway.
> - Harald had set up /dev/input/event<n> input subsystem stuff for
> bringing this to userspace, one per motion sensor chip. I did a hexdump
See patch 3/3 comment for more on that.
> - If the interrupts can't be fixed on the chips then we have to read
> from them asynchronously. Luckily the chips have a samples-ready bit,
This has gone away, the INT signals work with the patches.
> - If we don't see corruption from the I2C / SPI problem tomorrow we
> probably won't ever see it. It's because the I2C side SDA is hooked to
I didn't see any corruption yet.
Going to try to solve the SPI load problem now.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel