-
Notifications
You must be signed in to change notification settings - Fork 101
Support different pixel orders and RGBW strips #1
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
Comments
This is done. The constructor takes |
Reopening to address the pixel order part of the issue. How about this:
Ex: |
im cool w/this but rather than passing in "RGB" lets have a constant such as neopixel.RGB? |
Additionally, I'm fine with constants. So this: |
id leave |
There's a rough draft PR. Comment on it over there. Will make lint happy and update doc examples if this seems like the right approach. |
i think we can just have the RGBW = (0, 1, 2, 3) rather than index? |
Good call, was over thinking it. Removed the dict. |
Closing back up. Different pixel order support added by: #24 |
pixel_order missing from constructor param list
Right now the neopixel modules supports GRB order 400khz and 800khz pixel strips. We should update the module to support a wider range of pixel types:
RGB and other arbitrary byte orders
RGBW strips
This can probably all be done in the Python module as the low level pixel write function just takes an array of bytes to send out to the pixels (so it can change from 3-tuples to 4-tuples of color info for RGBW easily).
The text was updated successfully, but these errors were encountered: