[Bug] Subsequent I2C operations raise PBIO_ERROR_IO

[laurensvalk]

Describe the bug

Subsequent I2C operations raise PBIO_ERROR_IO. Apparently something is not ready, since a short wait seems to work around it.

It would be great if pbdrv_i2c_write_then_read waits for i2c it to become ready (unless existing timeout is hit first).

To reproduce

• Build the work branch at pybricks/pybricks-micropython@75711d8.

• Run the following. It should work, but errors show up when you reduce WAIT from 10 to 0.

from pybricks.iodevices import I2CDevice
from pybricks.parameters import Port
from pybricks.tools import wait

# Choose custom=True to allow any I2C device, skipping device detection.
dev = I2CDevice(Port.S4, 0x01, custom=True, powered=True, nxt_quirk=True)

# You get IO errors for 0 delay
WAIT = 10

CMD_READ_MANUFACTURER = bytes([0x08])
CMD_READ_PRODUCT = bytes([0x10])
CMD_READ_DIST = bytes([0x42])

wait(WAIT)

print(dev.write_then_read(CMD_READ_MANUFACTURER, 4))

wait(WAIT)

print(dev.write_then_read(CMD_READ_PRODUCT, 6))

while True:

    wait(200)

    data = dev.write_then_read(CMD_READ_DIST, 1)
    print(f"distance: {data[0]} cm")

Or just await two pbdrv_i2c_write_then_read sequentially from a pbio process.

[dlech]

When I try this, I just get:

Traceback (most recent call last):
  File "nxt-us.py", line 5, in <module>
OSError: [Errno 19] ENODEV: 

A sensor or motor is not connected to the specified port:
--> Check the cables to each motor and sensor.
--> Check the port settings in your script.
--> Check the line in your script that matches
    the line number given in the 'Traceback' above.

[dlech]

Oscilloscope shows that something is pulling down pin 1 a bit compared to ev3dev. On ev3dev, we get 4.9V which is above the 4.8V threshold in the DCM. On Pybricks, it is hovering around 4.8V, but the noise makes it dip below that, so the DCM isn't detecting it correctly.

[laurensvalk]

I'll push the I2CDevice shortly so I2C can be used without the DCM. (But I appreciate your tests on the ADC 😄 )

[laurensvalk]

Updated code and example above to optionally disable DCM, allowing any kind of I2C device in theory. Includes simple way to reproduce the IO errors.

[ArcaneNibble]

When I try my original test code (from a pbio process), the ultrasonic sensor indeed gives a bunch of NAK responses if you go too quickly, but the RPi Pico I've also been testing with (running a hacked version of this SDK example) is fine and never NAKs.

[dlech]

This vaguely rings a bell that the NXT Ultrasonic sensor was sensitive to trying to read too fast. So the right place for the delay would be in the Ultrasonic sensor driver, not the I2C driver. In ev3dev, IIRC, we made the max I2C sensor poll period 20 ms because of this (and CPU usage concerns). Making it 10 ms here is probably fine since we don't have to also run Linux.

[dlech]

Oscilloscope shows that something is pulling down pin 1 a bit compared to ev3dev. On ev3dev, we get 4.9V which is above the 4.8V threshold in the DCM. On Pybricks, it is hovering around 4.8V, but the noise makes it dip below that, so the DCM isn't detecting it correctly.

I think I tracked this down to pybricks/pybricks-micropython#375 (comment). We were off by about 50 mV which was causing the DCM theshold to not work correctly.

[laurensvalk]

Thanks both for having a look.

Yes, even at 10 ms when I2C is happy, the ultrasonic sensor distance values are capped to a low distance, so this would break user programs that poll to look for objects nearby.

So this one will probably get a background process component, along with the temperature sensor. The user will just get the latest value when asked. If there are popular I2C sensor where background polling is helpful, we can add them here too.

(This is much like the LUMP component of the port process that begins to run once the DCM detects such a device.)

Due to the way Pybricks works at a high level, we shouldn't have to probe known I2C address ranges like ev3dev but only assert if the requested sensor is not there.

[dlech]

we shouldn't have to probe known I2C address ranges

Even for a port view program? I guess that could be done at the Python level though if the port view program is written in Python.

[laurensvalk]

Can confirm that it works great back to back with the temperature sensor. Very cool!

we shouldn't have to probe known I2C address ranges

Even for a port view program? I guess that could be done at the Python level though if the port view program is written in Python.

We could do it in C or Python but it doesn't have to be in the background process running at all times.