Open scirelli opened 9 months ago
@ladyada where do you get the chip ids from? I'd like to update the list, if 0x43
is a valid chip id. Thanks!
It's baked into the firmware.
For ATtiny based seesaws (neodriver is one of these), the firmware is here:
https://github.com/adafruit/Adafruit_seesawPeripheral
and HW_ID
is set via preproc logic:
https://github.com/adafruit/Adafruit_seesawPeripheral/blob/313090f3a3839e1e5f8f0d7a81c6a6262f89f571/Adafruit_seesawPeripheral_request.h#L1-L15
For SAMD based seesaws, the firmware is here: https://github.com/adafruit/seesaw
The value itself comes from querying the Status function register for HW_ID
:
https://learn.adafruit.com/adafruit-seesaw-atsamd09-breakout/status
0x43
is not a valid chip id. Something else is happening and will need to be investigated. It may also be something specific to the FT232H.
Is this something I can help with? I'm now sure what I can do. I have the FT232H hooked up to a Mac, and even though I edited in the wrong hardware id, it's working and I can run the neopixel example code now. I had to reduce the frequency for it to work though.
I had to reduce the frequency for it to work though.
That's actually probably the best fix for getting it working with the FT232H. There is potentially a small amount of clock stretching happening with the seesaw chip, and the FT232H may or may not be handling that well. Slowing down the I2C frequency is a good work around.
With the slowed down clock, the id is probably reading correctly now as well. Can verify via REPL:
>>> import board, busio
>>> from adafruit_seesaw import seesaw, neopixel
>>> i2c = busio.I2C(board.SCL, board.SDA, frequency=10000)
>>> ss = seesaw.Seesaw(i2c, addr=0x60)
>>> ss.chip_id
135
>>> hex(_)
'0x87'
>>>
I had to reduce the frequency for it to work though.
That's actually probably the best fix for getting it working with the FT232H. There is potentially a small amount of clock stretching happening with the seesaw chip, and the FT232H may or may not be handling that well. Slowing down the I2C frequency is a good work around.
With the slowed down clock, the id is probably reading correctly now as well. Can verify via REPL:
>>> import board, busio >>> from adafruit_seesaw import seesaw, neopixel >>> i2c = busio.I2C(board.SCL, board.SDA, frequency=10000) >>> ss = seesaw.Seesaw(i2c, addr=0x60) >>> ss.chip_id 135 >>> hex(_) '0x87' >>>
Yes, now it does read the correct chip id! I'll close that other PR with a note.
Can we add a note to the example code that the frequency may need to be slowed down? I can do it if you point me to where it lives.
I have a FT232h connected to a Neopixel Driver board. They are connected via the FT232H STEMMA to the NeoPixel Drivers STEMMA connector.
Example code I'm testing with.
Error being raised:
The guide has me installing adafruit-circuitpython-seesaw I see where the error is being raise on lines 152-164.
pip install adafruit-circuitpython-seesaw
Is a new chip being used on the NeoPixel driver board, and the code hasn't been updated?
There are some other examples that setup the I2C with
I modified the example code I was using to test the FT232H and NeoPixel driver to use the above but that gives me this error:
===== Update ===== I took a look at the chip on the Neopixel driver board with a magnifying glass. It is an Attiny, the code on the chip is T1616-N. I edited this line in the source to change the ID to
0x43
, not0x67
because of this bug. The neopixels started to change colors, a rainbow pattern then died with this exception:~This looks like a bug in the example code. I will edit it and create a new issue and PR.~ Maybe not really a bug in the example, what I had to do to stop the error was to reduce the frequency:
~I will create a PR to add another chip ID for the Attiny1616 if that is a valid fix?~