Closed caternuson closed 2 years ago
It looks like there is some existing code that depends on the old (incorrect) behavior. For instance, the NeoKey1x4 driver has this:
https://github.com/adafruit/Adafruit_CircuitPython_NeoKey/blob/main/adafruit_neokey/neokey1x4.py:
self.pixels = NeoPixel( self, _NEOKEY1X4_NEOPIX_PIN, _NEOKEY1X4_NUM_KEYS, brightness=0.2 )
The NeoKey1x4 only has an 24-bit Neopixel, though, and with #102 setting a color now overflows the pixel buffer by 1 byte.
The neopixel trellis examples are broken, seems related to this. Reverting to 1.10.10 fixed the issue.
code.py output:
Traceback (most recent call last):
File "code.py", line 44, in <module>
File "adafruit_seesaw/neopixel.py", line 123, in __setitem__
ValueError: need more than 3 values to unpack
@vpicone Thanks. This is sort of whack-a-mole. Fix one thing and it breaks another thing that was relying on the semi-broken behavior. This is essentially a new issue. Opened one here: https://github.com/adafruit/Adafruit_CircuitPython_NeoTrellis/issues/18
@ladyada Any idea why the GRBW
default? instead of just RGB
?
https://github.com/adafruit/Adafruit_CircuitPython_seesaw/blob/1230da9e11381767c7298d41c029ba63672ee1a6/adafruit_seesaw/neopixel.py#L73
@caternuson can this be closed now?
@ladyada yep, i think so. i recreated original issue and verified fix. can reopen if needed if others still run into oddness.
The
bpp
parameter is being set separately from thepixel_order
parameter with a default value of3
, andbpp
has precedence. So the following example code results in unexpected behavior when using RGBW neopixels:By explicitly setting
bpp=4
in addition topixel_order
, the behavior is correct.