For the Raspberry Pi to communicate reliably using I2C to the DI/ModRobotics Inertial Measurement Unit (IMU), which is Bosch BNO055 based, the Raspberry Pi must implement I2C clock stretching.
It has been reported that the Raspberry Pi does not implement the clock stretching fully, and indeed I found that trying to use the Raspberry Pi hardware I2C to communicate with either the DI/BNO055 IMU or the Ivensense MPU-9250 IMU will fail miserably.
DI/ModRobotics has supplied interface code that automagically implements the clock stretching in software in di_I2c.py and extends the I2C bus onto the two configurable connectors AD1 and AD2. The DI IMU interface defaults to the AD1 connector.
There will still be some soft errors so users should use a try/except block to catch the errors and retry the operation. (If you see a zero temperature value when running the DI IMU example a soft error occurred.)
P.s. This concludes the full extent of my knowledge on this clock stretching issue.
I wonder if the Pi-4 and/or its latest firmware have addressed this issue, since the Pi-4 includes significant hardware improvements in the SOC.
Do you have some kind of simple script that I could “plop in place” on Charlie and run against the IMU, (the picky sensor), from either of the interfaces, (both hardware and software i2c) so that I can try to verify your results? on the Pi-4 platform?
Something that I could plop in place, sudo the heck out of it, let it run for a while, and look at a log somewhere to see what, if anything, is happening?
I might be tempted to make a small modification that would cause Dex’s eyes to light different colors while the test is running to indicate the presence or absence of errors.