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