Fee FiFo Fum, Feck

After a lot of timing experimentation today*, I’m pretty certain my I2C errors (and duff data) are due to the MPU-9250 sensor registers being updated while I’m still reading them.  If so, I need to move to using the FIFO provided.

I opted to read the data registers directly originally for simplicity, and then (when I found a single I2C ready could return multiple bytes of data) for performance.

Swapping to the FIFO is going to be a right pain.  It’s essentially a pipeline of bytes with data from the sensor fed in at the bottom, and read at the top.  But the bytes can only be read byte-by-byte (still over an I2C interface), so care needs to be taken to build a full set of bytes before processing that next batch from the sensors.  It does have a latch to hold-back updates while reads are happening which is good.

However, I think it also makes the hardware interrupt meaningless – the count of data in the FIFO is just polled over I2C and if greater than a complete batch, read the next full batch of data.  That’s messy as it’s a CPU hog, and is going to rule out having ‘spare CPU’.

Or putting it another way, it’d be better left to an Arduino (penny in the swear box) to hard-loop reading the FIFO as new data is queued up.


*I tried

  • different model A+’s
  • different MPU-9250 (Chloe’s and Phoebe’s)
  • a kernel update (sudo rpi-update)
  • various I2C baudrates (100, 200 and 400kHz)
  • various overclocking from 750MHz to 1GHz
  • setting combined=1 in /etc/modprobe.d/i2c_bcm2708.conf
  • various SMPLRATE_DIV settings for the sensor sampling

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.