This arose from this forum thread. This driver for the Bosch BNO055 IMU has been tested on Pyboards, ESP32 and ESP8266 but has proved problematic on the Pico. Investigation showed that the IMU indulges in clock stretching for varying periods. The longest I have observed is 500μs.
Hard I2C
Hard I2C, invoked as below, fails almost immediately with an EIO error.
i2c = machine.I2C(0, sda=machine.Pin(16), scl=machine.Pin(17))
By contrast, hard I2C works on Pyboards and on ESP32.
Soft I2C
On RP2 soft I2C must be invoked with a higher timeout value:
i2c = machine.SoftI2C(sda=machine.Pin(16), scl=machine.Pin(17), timeout=100_000)
Subsidiary question. On ESP32 and ESP8266, soft I2C works with the default timeout. This now seems surprising.
Should the default timeout be increased?
This arose from this forum thread. This driver for the Bosch BNO055 IMU has been tested on Pyboards, ESP32 and ESP8266 but has proved problematic on the Pico. Investigation showed that the IMU indulges in clock stretching for varying periods. The longest I have observed is 500μs.
Hard I2C
Hard I2C, invoked as below, fails almost immediately with an EIO error.
By contrast, hard I2C works on Pyboards and on ESP32.
Soft I2C
On RP2 soft I2C must be invoked with a higher timeout value:
Subsidiary question. On ESP32 and ESP8266, soft I2C works with the default timeout. This now seems surprising.
Should the default timeout be increased?