Closed knoxvillesjoker closed 2 years ago
thanks yknow i never ever had to do this... but we can add a note in the guide about it. we could also change the pullups to be 2.2K - but they wouldnt be uneven, just stronger - whatcha think?
Well if you want me to test something, I have no issues purchasing a new demo unit and testing things. Too many losses have been endured by all of late and I will refuse to ask or demand anything for free as that purchase could buy someone a dinner for their child.
I just have concerns that the chip itself may not be compatible with the raspberry pi on I2C. From what I read the updates were to address an SPI communications issue. As far as troubleshooting I have run it down to just the raspberry pi and this unit and still get the issue so I definitely think it is a hardware based issue or it could be software based where not enough logic is added to account for the clock stretching.
My programming abilities are not to the deity levels of some of the folks at adafruit. Not my favorite thing to do, but I can always parse and reverse engineer what I need to make things work and document for the community to try and help others avoid my struggles.
All that said I think I will get another pi zero w and see how behavior is on SPI and UART mode, which I avoided as the pins were occupied in my setup. As far as my readings on SPI, since I was using a TFT display I thought those pins were in use and SPI only allows 1 maybe 2 devices if setup correctly.
no need to test, if we hear anything now we know and can refer them to this issue for debugging :)
I did some more digging and there is a solution. I will need to test things on it though.
https://github.com/fivdi/i2c-bus/blob/master/doc/raspberry-pi-software-i2c.md
Apparently the hardware i2c does not support clock stretching but a software implementation would.
Can confirm the software i2c driver fixed the issue with clock stretching on a Pi 0.
The BNO085 i have just bought has issues with the I2C not working. it doesnt see the pullup resistors. i recon there is still a bug with the hardware/software somewhere
@knoxvillesjoker or @ocouch so what's the recommended way of using this? Software I2C or resistors or both?
@fgolemo any success?
@ladyada any experience here? I bought 15 of these breakouts (Adafruit BNO085) specifically with I2C in mind (since the breakout board advertises STEMMA connectors), but the examples posted to work with RPi just return various errors (unknown report type, key error, etc)
I'm using a RPi Zero W v1.1; here are the configurations I've tried:
busio
, no external pullups added, frequency set to 400000
busio
, no external pullups added, frequency set to 400000
, timeout set to 1000
(mentioned in https://github.com/adafruit/Adafruit_CircuitPython_BNO08x/issues/33#issuecomment-968797861), but this errored because apparently timeout is not applicable/ignored for busioadafruit_bitbangio
, no external pullups added, frequency set to 400000
, but I don't expect this to work. I believe that software I2C needs I2C actually disabledadafruit_bitbangio
, no external pullups added, frequency set to 400000
adafruit_bitbangio
, no external pullups added, frequency set to 400000
, timeout set to 1000
I'm going to keep trying, but it would be great if we could get more insight on what a valid software/hardware config looks like
@seesemichaelj Did you try the suggested fix for clock stretching? You only mention using 400000
bus speed.
https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/i2c-clock-stretching
The software I2C approach mentioned above is another possible option. For that, this library is used: https://github.com/adafruit/Adafruit_Python_Extended_Bus
@ladyada I think maybe this can be closed? Seems like it's a pi / clock stretch thing?
No, I did not change the clock via the boot config; I'll give that a shot
It does seem I missed this excerpt in the docs here that do briefly mention the clock stretch
Perhaps that could be pulled out to have a separate header to separate it from the "wiring" section as it's easy to pass over.
Oh yah, there is that specific to the BNO85, but also as mentioned "seems to work best".
I'd suggest trying the i2c-gpio overlay (software I2C).
I can confirm that making the above change to /boot/config.txt
finally gets things working with this config:
busio
: i2c = busio.I2C(board.SCL, board.SDA, frequency=400000)
(so not software I2C)I believe that the docs could be modified slightly to call it out the necessary change more, but it seems I'm running the example without errors reliably
i made the text red, so maybe folks will be more likely to read it.
It's perfect, thank you @ladyada!
as noted here: https://github.com/jps2000/BNO080 Try my unequal-pullup trick to see if it fixes your I2C problem. It's easy to do, and it worked on my Hillcrest and SparkFun BNO080 breakouts:
The BNO055, BNO080, and probably the BNO085 all have the same I2C timing error. When the BNO ends a clock-stretching cycle, the SDA-to-SCL setup time is occasionally on the verge of failure. My unequal pullup trick creates unequal rise times, thereby increasing the SDA-to-SCL setup time
It appears that this is a similar issue to the mpu-6050 i2c bus issue and a core design issue of that board requiring a redesign to properly address. From my thread on adafruit as I work through some issues: https://forums.adafruit.com/viewtopic.php?f=50&t=170935&p=836618#p836618
Stepping down into the python console and initializing the board I am getting intermittent packet communications errors with the bno088 with or without the suggested resistor fix.
I step over and use an mpu-6050 without issues on the raspberry pi which tells me this is either hardware, software, or both as a cause in nature.