Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Neopixel library doesn't support RGBW LEDs #2478

Closed
jrobeson opened this issue Oct 5, 2016 · 10 comments

Comments

@jrobeson
Copy link

commented Oct 5, 2016

Naively, I didn't take into account that these LEDs were RGBW, so I tried running the example code:

import machine, neopixel
np = neopixel.NeoPixel(machine.Pin(4), 8)
np.fill((0, 64, 0))
np.write()

Of course, that results in odd behavior. Not all LEDs light up, or light up in odd colors.

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?

I'd be willing to submit a PR if you folks tell me how you want it to act.

@jrobeson

This comment has been minimized.

Copy link
Author

commented Oct 5, 2016

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

@mcauser

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2016

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

@jrobeson

This comment has been minimized.

Copy link
Author

commented Oct 5, 2016

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.

@deshipu

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2016

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.

@deshipu

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2016

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.

@dpgeorge

This comment has been minimized.

Copy link
Member

commented Oct 6, 2016

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).

@dpgeorge

This comment has been minimized.

Copy link
Member

commented Oct 6, 2016

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.

@jrobeson

This comment has been minimized.

Copy link
Author

commented Oct 6, 2016

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

@puuu

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2016

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.

@dpgeorge

This comment has been minimized.

Copy link
Member

commented Oct 25, 2016

The driver now supports RGBW LEDs (see above).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.