![Cool 8-)](./images/smilies/icon_cool.gif)
Pico and BNO055 IMU
-
- Posts: 18
- Joined: Mon Jan 03, 2022 1:29 pm
Re: Pico and BNO055 IMU
I doubt I need to say this, but I have no idea. Well done for spotting a fault though! ![Cool 8-)](./images/smilies/icon_cool.gif)
![Cool 8-)](./images/smilies/icon_cool.gif)
Re: Pico and BNO055 IMU
Thank you for confirming this error.pythoncoder wrote: ↑Tue Jan 11, 2022 11:18 amOK, I've now run the test script and can confirm there is a problem, but only on the Pico ........
For several months now I have had the feeling that without the official submission of this dire bug in Github, there will be no real answers and solutions.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Pico and BNO055 IMU
On current evidence it may not be this simple. It's possible that the BNO055 does indulge in clock stretching. If it occasionally clock-stretches for >255μs the timeout errors on the Pico soft I2C are correct. I've figured out a way to check for this which I'll try tomorrow....this dire bug...
If it does, the questions will then be:
- Why does hardware I2C not work on the Pico?
- Why does soft I2C not fail with a timeout error on ESP32 and ESP8266?
- How does hardware I2C handle clock stretching on Pyboard and ESP32?
![Wink ;)](./images/smilies/icon_e_wink.gif)
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Pico and BNO055 IMU
Yeah well, maybe I'm biased now.pythoncoder wrote: ↑Tue Jan 11, 2022 6:22 pmBefore sounding off on GitHub I'd like to make sure we've got our facts straight![]()
Pi Pico with Micropython has given me a lot of migraines over the past few months.
![Confused :?](./images/smilies/icon_e_confused.gif)
I am still very excited about your tests.
PS: Another question would be:
Why does circuit python harmonize so much better with the Pi Pico?
![Wink ;)](./images/smilies/icon_e_wink.gif)
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
The verdict
I've looked at the I2C waveforms in detail. The BNO055 performs clock stretching a great deal, usually for short periods but occasionally for longer periods. The longest I have observed is 500μs, which accords with the need to increase the timeout from the default 255μs.
Hard I2C on the Pico fails almost immediately: it seems that it cannot handle clock stretching. This is the one actual bug on the Pico, although there may be a case for increasing the default timeout.
I will raise an issue on GitHub.
As for CircuitPython it is aimed at users with less technical knowledge. As such it loses the most interesting features of MicroPython such as interrupts and asynchronous coding, but it gains in "plug and play" ease of use. In any event RP2 is still relatively new, there are bound to be a few teething troubles. FWIW I've found it very stable and relatively bug-free.
Hard I2C on the Pico fails almost immediately: it seems that it cannot handle clock stretching. This is the one actual bug on the Pico, although there may be a case for increasing the default timeout.
I will raise an issue on GitHub.
As for CircuitPython it is aimed at users with less technical knowledge. As such it loses the most interesting features of MicroPython such as interrupts and asynchronous coding, but it gains in "plug and play" ease of use. In any event RP2 is still relatively new, there are bound to be a few teething troubles. FWIW I've found it very stable and relatively bug-free.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Pico and BNO055 IMU
I have raised this issue.
I encountered some invalid data running at 400KHz. A scope revealed waveforms with slow risetimes, a consequence of the Adafruit board's 10KΩ pullups. Adding 1KΩ pullups fixed the waveforms. The test script now runs reliably for long periods. Perhaps the Pico pins have higher capacitance than those of other platforms.
I encountered some invalid data running at 400KHz. A scope revealed waveforms with slow risetimes, a consequence of the Adafruit board's 10KΩ pullups. Adding 1KΩ pullups fixed the waveforms. The test script now runs reliably for long periods. Perhaps the Pico pins have higher capacitance than those of other platforms.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Pico and BNO055 IMU
I am very interested in whether a solution will be found there!
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Pico and BNO055 IMU
I thought I'd described the solution:
- Ensure you have 1KΩ pullups to 3.3V on the two I2C lines.
- Use soft I2C invoked as below with a timeout value.
Code: Select all
i2c = machine.SoftI2C(sda=machine.Pin(16), scl=machine.Pin(17), timeout=100_0000)
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: Pico and BNO055 IMU
I apologize for my incorrect phrasing. I meant a solution regarding Hard I2C.
Re: Pico and BNO055 IMU
Except there won't be one for hardware I2C, because the BNO055 IMU requires clock stretching, something the Pico's hardware I2C doesn't support