Add support for explicit 32-bit WS2812-compatible LED transfers, enabling direct use with RGBW devices such as SK6812 RGBW.
When .32 is specified, LED mode now:
configures the PIO autopull threshold for 32 bits,
transmits the complete uint32_t value without the existing 8-bit shift.
The existing behavior is preserved for default and explicit .24 transfers.
Examples
[ 0xff0000
[ 0xff0000.24
Both continue to transmit a 24-bit RGB value.
[ 0x01020304.32
Now transmits all four bytes instead of dropping the most significant byte.
Implementation
The WS2812 PIO state machine is reconfigured between 24-bit RGB and 32-bit RGBW operation when the requested transfer width changes. The code waits for the current transfer to finish before reinitializing the state machine.
APA102 and onboard LED handling are unchanged.
Testing
Bus Pirate 5 rev10 firmware build with Pico SDK 2.1.1
Thank you for this update. I am going to add this feature, but I am also going to add it as a command line/menu option.
HiZ> m led -d ws2812 -f rgbw
Mode: LED
LED-(WS2812)> m led -h
options:
-d, --device <ws2812|apa102|onboard>
-f, --format [rgb|rgbw]
-h, --help Get additional help
LED-(WS2812)> m led -d ws2812
Mode: LED
Not quite there yet, but here is the current prototype.
Some feedback that I understand you might not take:
-d/--device – change to -t / --type, as it indicates which pixel type
-f/--format – Allowing rgbw and rgb is OK, but what this is really doing is changing how many bits are processed by the script by default from each 32-bit value. Maybe make the options: <rgb|rgbw|24bpp|32bpp> to reflect bit per pixel, which happens to be a perfect explanation of what’s changing?
For type=APA102, add parameters --data and --clock? (using BPIO pin #s … and restricting to pins that are consecutive, if needed by the .PIO program?)
For type=WS2812, add parameter --data, and allow special pin of “Internal” to control internal WS2812 pixels.
Use the terms “Pixel” and “LED”; Each pixel typically has 3-4 LEDs embedded in it. As a contributed to FastLED, WLED, and others, the clarity this brings in the long run is (imho) worthwhile.
Henry beat me to it, but this is my current hang up. RGB isn’t actually giving RGB ordered access to the pixels, it is 24 bits/pixel. 24bpp and 32bpp seem like good choices.
Another route is to allow an arbitrary number of bits per pixel. 1-32?
