Adding delay for third-party nunchuks

[BlitzCityDIY]

hihi- @djecken was using this library with the nunchuk that we sell in the shop and kept getting an error that no device was on 0x52 despite the I2C scan test showing the device. we switched to an official nunchuk and didn't get this error. i ran into this when working on the wii_classic library. third-party controllers seem to take longer to initialize for some reason. i added the same try/except loop here and that has fixed the issue with the nunchuk in the shop.

[caternuson]

I have one of those nunchuk's also. What's the complete hardware setup being used? Will try and recreate this.

Wondering if _I2C_INIT_DELAY and/or i2c_read_delay could be used to help with this.

[BlitzCityDIY]

it's the nunchuk breakout connected via a STEMMA QT cable to the STEMMA QT port on the Feather RP2040 RFM69. i had tried increasing the init delay previously and added a time.sleep all the way up to 10 at the top of code.py but it didn't seem to do the trick

[caternuson]

Don't have the RFM Feather, but looks like can recreate the same general issue with a basic Feather RP2040:

Adafruit CircuitPython 8.0.5 on 2023-03-31; Adafruit Feather RP2040 with rp2040
>>> import board
>>> from adafruit_bus_device.i2c_device import I2CDevice
>>> i2cdev = I2CDevice(board.I2C(), 82)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: No I2C device at address: 0x52
>>> i2cdev = I2CDevice(board.I2C(), 82)
>>>

Fails on first attempts. Succeeds on second. It's failing in the probe for device:

Adafruit CircuitPython 8.0.5 on 2023-03-31; Adafruit Feather RP2040 with rp2040
>>> import board
>>> i2c = board.I2C()
>>> i2c.try_lock()
True
>>> i2c.writeto(82, b"")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 19] No such device
>>>  

The same thing works on a Feather M4:

Adafruit CircuitPython 8.0.5 on 2023-03-31; Adafruit Feather M4 Express with samd51j19
>>> import board
>>> i2c = board.I2C()
>>> i2c.try_lock()
True
>>> i2c.writeto(82, b"")
>>> 

So something RP2040 specific. Maybe with the empty write? Going to scope this to investigate further.

[caternuson]

Another interesting point - it works on the RP2040 with an official Wii Nunchuk:

Adafruit CircuitPython 8.0.5 on 2023-03-31; Adafruit Feather RP2040 with rp2040
>>> import board
>>> i2c = board.I2C()
>>> i2c.try_lock()
True
>>> i2c.writeto(82, b"")
>>>

So it's the combo of RP2040 + 3rd party nunchuk.

[caternuson]

Looks like a scan can be used to "wake it up" also. This is back with the 3rd party nunchuk:

Adafruit CircuitPython 8.0.5 on 2023-03-31; Adafruit Feather RP2040 with rp2040
>>> import board
>>> i2c = board.I2C()
>>> i2c.try_lock()
True
>>> _ = i2c.scan() ; i2c.writeto(82, b"")
>>> 

[BlitzCityDIY]

yes that's been my finding too- official works fine with library as-is, third-party has the problem

[caternuson]

This is something specific to the RP2040 and the 3rd party Nunchuck. The behavior of the zero byte write done in I2CDevice._probe_for_device() with a Feather RP2040 and PID 342 controller is:

The behavior with an official Wii Nunchuck is:

The large gap between the start and write is odd and something RP2040 specific. The 3rd party controller ends up NAKing the write while the Wii one ACKs.

[caternuson]

@BlitzCityDIY An I2C scan seems to also work. What do you think of something like this?

    def __init__(
        self, i2c: I2C, address: int = 0x52, i2c_read_delay: float = 0.002
    ) -> None:
        self.buffer = bytearray(8)
        #-| HACK |---------------------------------------------------
        # fixes quirk with RP2040 + 3rd party controllers
        while not i2c.try_lock():
            pass
        _ = i2c.scan()
        i2c.unlock()
        #------------------------------------------------------------
        self.i2c_device = I2CDevice(i2c, address)
        self._i2c_read_delay = i2c_read_delay
        time.sleep(_I2C_INIT_DELAY)
        with self.i2c_device as i2c_dev:
            # turn off encrypted data
            # http://wiibrew.org/wiki/Wiimote/Extension_Controllers
            i2c_dev.write(b"\xF0\x55")
            time.sleep(_I2C_INIT_DELAY)
            i2c_dev.write(b"\xFB\x00")

[BlitzCityDIY]

@caternuson cool yeah i think that's good

[caternuson]

OK. esp. want to have some very prominent comments about this being a hack to deal with a quirk. It's possible the behavior seen above in the scope traces could get changed (fixed?) via an update to the RP2040 code in the CP core. And then maybe the 3rd party controllers will be OK? (maybe??). But AFAIK, there's currently nothing else being affected by that RP2040 behavior. So shouldn't wait/hope for those core changes to happen to fix the issue here. Thus - a hack is needed :(

[BlitzCityDIY]

totally yeah it seems that we've stumbled upon a deep edge case 🙂

[caternuson]

Yep. I believe the fancy tech term for this is "feature".

Wanna test that change on your setup to double check it works there also and then update PR?

[BlitzCityDIY]

@caternuson yes just tested with the RFM feather and nunchuk from the shop and that fix is working consistantly. will update meow

[github-actions]

👋 Thanks for this pull request! Unfortunately, it looks like the automated continuous integration (CI) test(s) failed. These can be tricky to fix so we've written a guide on how to fix them locally. It has pages about running pre-commit locally and another about building the docs locally with sphinx. Thanks for contributing to CircuitPython! If you have more questions, feel free to join the Adafruit Discord and post in #circuitpython-dev.

[caternuson]

cool. thanks. LGTM.

one other idea to toss here just to document, could add a check for RP2040 and only run hack on that:

Adafruit CircuitPython 8.0.5 on 2023-03-31; Adafruit Feather RP2040 with rp2040
>>> import sys
>>> sys.platform
'RP2040'
>>>  

but i think OK to keep it simple for now and just run the hack for all. we'll see how this work when released into the wild.