4 byte colors are mentioned in PR that added fill() #2033

There are 3 common versions of the LED strips. Each letter below represents a pixel colour.

• GRB - most 3 color neopixel products
• RGB - v1 Flora pixels
• RGBW - new 4 colour neopixel products

You may need to change the order of the bytes in the array when adding w. (GRB -> RGBW)

The current MicroPython NeoPixel class only deals with GRB.
To support 3 and 4 colour strips, almost every method in the class would need to be rewritten. Perhaps a 2nd class specific to 4 colour strips would be more efficient. eg. NeoPixelRGBW

The Adafruit Arduino library supports all permutations for R,G,B,W with macros.
https://github.com/adafruit/Adafruit_NeoPixel/blob/master/Adafruit_NeoPixel.h

I wonder if we'll see GRBW pixels or some other order variation. I don't know that much about LED strips to know how likely that is though.

You can always specify the colors in a different order -- as long as you have support for the given number of colors. This is a little bit harder with rgb vs rgbw.

By the way, I'm not sure if it's a good idea (probably not), but it would be possible to have a single class that just behaved differently depending on whether the color is specified as a triple or quintuple. That won't work for getitem, though.

The underlying esp.neopixel_write function does not need to change because the timing is the same. It's just the Python wrapper class.

Simply changing the 3 to 4 for self.buf and adding a w entry to the tuple in neopixel.py makes it work correctly. Of course, doing that directly would break it for folks with regular RGB LEDs. What would be the appropriate design choice here?

It would be possible to generalise NeoPixel class to take as an argument (to the constructor) the number of bytes per pixel, eg: np = NeoPixel(pin, 8, 4). All methods could be rewritten to be generalised to argibrary bytes_per_pixel (or bpp), and might even take less bytecode because you don't repeat the code to set/get the pixels (it's now in a loop).

It would be possible to generalise NeoPixel class to take as an argument (to the constructor) the number of bytes per pixel

Actually, it's not as easy as I thought, because for bpp=3 you have a different ordering of the RGB values compared to bpp=4. And to support different orderings would mean a lot of extra code.

So it's probably simpler (less code, more efficient) to just have a NeoPixelRGBW class.

I was quoting the label which says RGBW, but the internal ordering on these strips is actually the same as the current code. I didn't realize I had some colors crossed. So everything does work as expected just by changing the multiplier and adding an entry to the tuple

Hi,
I can confirm. I have a 1 m LED strip light with RGBW SK6812. The internal byte order is green, red, blue and white. This means, the ordering of the RGB values is the same for bpp=3 and bpp=4.

The driver now supports RGBW LEDs (see above).