Motion Sensor Status

Andy Green andy at
Thu Jan 24 00:55:39 CET 2008

Hash: SHA1

Hi folks -

Here's a status for today

 - 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.

 - 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

 - 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.

 - 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

 - 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
on it and there is timestamp content but no X Y Z information: but I
understood with this event interface stuff I need to use something that
fires the right IOCTL to set the mode somehow... any ideas what I can
use that is already on the device to confirm data is in there?  Hook it
up to X somehow maybe or some X tool?

What it means is we need to go on tomorrow and confirm we can get
sensible data from both chips without trouble, if it is true then what's
on A5 will probably be adequate, known problems would reduce down to these:

 - 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,
so it just means we need to poll at ~1.2 x the sample rate and skip if
new samples are not ready.  Repeating samples is avoided but there is
large uncertainty about the true sample *time* left to worry about.  And
we have to poll all the time we might expect something from the sensor.
 Conversely if we can find a fix from ST maybe, this can just go away as
a concern.

 - 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
the CPU output signal for SPI, therefore the chance for corruption is
controlled by the CPU output side of our SPI traffic only, and that is
deterministic and covers a small set of transactions.  This problem
should not be sensitive to the data returned by the chip which is
nondeterministic for example.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list