-----BEGIN PGP SIGNED MESSAGE----- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHl9P7OjLpvpq7dMoRAno5AJoDN4lxwVlrHS53JSIl5B65+XAZaACdEMfJ RyhTWoNUUfXNg6QC37W9Aeg= =mQV5 -----END PGP SIGNATURE-----
