Yup, exactly.
That said... I just looked at this code more closely. The constant at the top does nothing. It would seem that the tile always responds to the address 1 (is this a feature of the firmware on this tile?), but can be configured with a specific address, defaulting to 60.
For some reason the code defaults all methods to using 1. (Would probably be better if the methods were all `def foo(..., addr=LED_ADDR):` )
Note that it appears you have to power cycle the tile to get it to recognise the address change. But I was able to change mine, and it still always responds to 1.
Also, for reasons that aren't clear to me, you still have to set the brightness before you can change the i2c addr?? I haven't read the datasheet in detail yet though.
Code: Select all
>>> led36.set_i2caddr(addr=60, oaddr=70)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "led36.py", line 39, in set_i2caddr
File "led36.py", line 32, in save_nvram
OSError: [Errno 19] ENODEV
>>> led36.brightness(100)
>>> led36.set_i2caddr(addr=60, oaddr=70)
>>>
{Edit:
It doesn't appear to be setting the brightness that's important, it's just that there's something about the initialization. The datasheet says "After power up LED36 waits for a SOH character (0x01) to start operation", but setting the brightness doesn't do this. I'm guessing by "All connected LED36 modules can be activated with a single byte sent to the I2C broadcast address 1." that it's literally that it's seeing a 0x01 on the bus, which would be if you were addressing addr=1, (except that would actually be 0b00000010 (7-bit + write)).
I'm also intrigued by "The first tile uses the default address 60, other tiles, currently up to 16, use successive addresses." does that mean that the devices on the same bus are aware of eachother and can automatically sequentially-assign addresses? How does that interact with setting the i2c address manually? Sounds neat though!
}