Closed TwoTenPvP closed 3 years ago
yeah it could be due to the clock stretching on i2c you may want to reduce the number of reports, and slow down i2c
yeah it could be due to the clock stretching on i2c you may want to reduce the number of reports, and slow down i2c
Is there no other ways? I really do need these reports.
well why not try to speed up i2c? could also try UART
Try just slowing down first: https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/i2c-clock-stretching
I have tried slowing down my clock to 10KHz as per that article.
Seems it just takes a few seconds for any interaction between my BNO and Raspberry pi now.
I really fail to understand this, perhaps one of you could explain it to me. How is the BNO intended to be used? Over I2C or UART? I need all the features I have enabled, I need it at a fast rate. ~50Hz.
How is the chip intended to be used? Surley this is not a wierd usecase? It's one I could easily accomplish with my old IMU.
Actually, just found this article: https://cdn-learn.adafruit.com/downloads/pdf/bno055-absolute-orientation-sensor-with-raspberry-pi-and-beaglebone-black.pdf and it states that for Raspberry Pi. UART should be used.
Thanks for your help anyways guys! Very much appreciated!
If you can get the data rate you want with UART, then should be fine.
If you need to continue to try I2C, then you'll be dealing with the clock stretching issue. This is a feature of the I2C protocol, but the Raspberry Pi does not handle it well and is a known issue. (Pi 4 may be different?) Not all I2C devices do clock stretching. However, the BNO08x apparently does. Similar to the BNO055.
The clock slow down is one approach for getting around the issue. Another approach to investigate would be the use of software I2C via the i2c-gpio device tree overlay.
I tried UART. And it does not have the data rate I need. So I am going with software I2C (thanks for the pointer @caternuson). I guess this might be the wrong forum to ask, but I am not quite sure about the API regarding the board pins.
I setup my i2c-gpio like this: dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=27,i2c_gpio_scl=22
. The busio API however seems to take some arbitrary pin numbers in it's constructor. Putting in 27 and 22 won't work.
Any pointers?
You'll want to use this library instead: https://github.com/adafruit/Adafruit_Python_Extended_Bus and just give it the bus number.
Thank you very much @caternuson. Works wonderfly!
For people in the future who need high data rate on the Raspberry Pi. Here is my guide:
/boot/config.txt
file: dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=27,i2c_gpio_scl=22
. By default it will use GPIO 23 and 24. But I was already using them so I specified the ports as a parameter. It's however optional.ls /dev | grep i2c
. You should see a i2c-3
(bus 3)
import adafruit_bno08x
from adafruit_bno08x.i2c import BNO08X_I2C
from adafruit_extended_bus import ExtendedI2C as I2C
bno = BNO08X_I2C(I2C(3))
Big thanks to the people in this thread!
Thank you very much @caternuson. Works wonderfly!
For people in the future who need high data rate on the Raspberry Pi. Here is my guide:
- Enable software I2C by adding the following entry to your
/boot/config.txt
file:dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=27,i2c_gpio_scl=22
. By default it will use GPIO 23 and 24. But I was already using them so I specified the ports as a parameter. It's however optional.- Reboot to apply the effects.
- Double check with
ls /dev | grep i2c
. You should see ai2c-3
(bus 3)- Using the PythonExtendedBus. The following code can be used:
import adafruit_bno08x from adafruit_bno08x.i2c import BNO08X_I2C from adafruit_extended_bus import ExtendedI2C as I2C bno = BNO08X_I2C(I2C(3))
Big thanks to the people in this thread!
it is old thread. but @TwoTenPvP you are the best i struggle with this problem over a weak. tanks alot for the example.
When listening to many different events on I2C. I get the attached stacktrace after some time.
I am running a Raspberry Pi 4B.
The less reports I enable the larger the sequence number (I.E it takes longer for the problem to occur). I assume this has to do with bandwidth restrictions on I2C? But I am by no means an expert. Looking for a way to solve it. Thanks!