Gemma M0 gives OSError: 5 on i2c.writeto to tinyLiDAR
Moderators: adafruit_support_bill, adafruit
Please be positive and constructive with your questions and comments.
- tannewt
- Posts: 3304
- Joined: Thu Oct 06, 2016 8:48 pm
Re: Gemma M0 gives OSError: 5 on i2c.writeto to tinyLiDAR
I'm not sure having the TinyLidar disconnected will help because the device won't ACK the address byte then and the host should stop sending. Did you give shifting the data in CircuitPython a shot?
- kevinjwalters
- Posts: 1025
- Joined: Sun Oct 01, 2017 3:15 pm
Re: Gemma M0 gives OSError: 5 on i2c.writeto to tinyLiDAR
Got some time to return to this problem.
I was disconnecting tinyLiDAR to determine if master was not sending 9th SCL pulse or slave was suppressing it by dragging SCL low, latter appears to be the case.
Turning up the sample frequency on analyzer shows activity better, I was losing a short SCL pulse at 500kHz sample on the 100kHz bus. The tinyLiDAR's STM32L (see below) appears to be holding the clock low for an additional 8.4us and then a slightly shorter 3us 9th clock pulse pops out for the ACK. This was probably "lost" when I had sample frequency set lower on analyzer and this isn't high-MHz 'scope output.
There's a good, detailed description of how the Raspberry Pi's i2c has problems in this area on http://www.advamation.com/knowhow/raspb ... c-bug.html which is attributed to the Broadcomm BCM2835 not supporting all forms of clock stretching. I think may be what they refer to as the "the slave stretches SCL at the beginning of an I2C-write-ACK-phase" scenario, I hadn't read much about the detail of this before but there appear to be difference places in the wire protocol where the clock can be stretched by the slave. Not all i2c implementations deal with all of them well. For Pi the tinyLiDAR recommendation on http://www.instructables.com/id/TinyLiDAR-on-a-Pi/ is to use http://abyz.me.uk/rpi/pigpio/ . For Arduino to use DSSCircuits library.
I think this could be a similar issue on the i2c code for Gemma M0 / ATSAMD21 / CircuitPython?
I was disconnecting tinyLiDAR to determine if master was not sending 9th SCL pulse or slave was suppressing it by dragging SCL low, latter appears to be the case.
Turning up the sample frequency on analyzer shows activity better, I was losing a short SCL pulse at 500kHz sample on the 100kHz bus. The tinyLiDAR's STM32L (see below) appears to be holding the clock low for an additional 8.4us and then a slightly shorter 3us 9th clock pulse pops out for the ACK. This was probably "lost" when I had sample frequency set lower on analyzer and this isn't high-MHz 'scope output.
There's a good, detailed description of how the Raspberry Pi's i2c has problems in this area on http://www.advamation.com/knowhow/raspb ... c-bug.html which is attributed to the Broadcomm BCM2835 not supporting all forms of clock stretching. I think may be what they refer to as the "the slave stretches SCL at the beginning of an I2C-write-ACK-phase" scenario, I hadn't read much about the detail of this before but there appear to be difference places in the wire protocol where the clock can be stretched by the slave. Not all i2c implementations deal with all of them well. For Pi the tinyLiDAR recommendation on http://www.instructables.com/id/TinyLiDAR-on-a-Pi/ is to use http://abyz.me.uk/rpi/pigpio/ . For Arduino to use DSSCircuits library.
I think this could be a similar issue on the i2c code for Gemma M0 / ATSAMD21 / CircuitPython?
- kevinjwalters
- Posts: 1025
- Joined: Sun Oct 01, 2017 3:15 pm
Re: Gemma M0 gives OSError: 5 on i2c.writeto to tinyLiDAR
Actually, I've found a way to make this work, write/read/pause appears to be the magic required for a loop.
Looking back at the Arduino example C code there is a pause in there, value is in milliseconds:
I'd hope that this would still work without a pause but perhaps a 'short' Circuitpython/Gemma M0 i2c timeout gets hit and things go bad after that.
I'll do some more methodical testing later with logic traces but the answer for now appears to be to follow the example C code and always pause after a tinyLiDAR D command.
Looking back at the Arduino example C code there is a pause in there, value is in milliseconds:
Code: Select all
delay(100); // delay as required (30ms or higher in default single step mode)
I'll do some more methodical testing later with logic traces but the answer for now appears to be to follow the example C code and always pause after a tinyLiDAR D command.
Please be positive and constructive with your questions and comments.