You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is in existence sets of intelligent LEDs known commonly as NeoPixels but more properly as WS2812 and similar numbered devices. These LEDs have extremely intricate timing requirements and can not be natively driven by OS's that have pre-emption capabilities such as Windows and Linux. The Raspberry Pi for example can not drive them directly. There are Arduino and ESP8266 libraries that can.
What this issue suggests is the creation of a new protocol extension to be able to drive these LEDs. To set the color of an LED, we send in 24 bits of information. 8 bits for the red, 8 for the green and 8 for the blue. Since one can daisy chain these LEDs together, the suggestion is for the protocol to take as data the following:
2 bytes - count of LEDs - allowing up to 65535 (we do have chains > 255 so 1 byte is insufficient)
3 bytes of RGB data * count of LEDs
If we believe that this notion has merit and would notionally be accepted as a submission ... then I for one will be happy to go to the next level and write up a detailed neopixel-proposal.md file. However, before I spend time on that, I wanted to get a "pulse" on the acceptability of such a submission. If it holds no merit or is otherwise outside the strategy of Firmata then that will be that.
Neil
The text was updated successfully, but these errors were encountered:
There is already a proposal here: #18 but no work has been done on it for a long time because an i2c-backpack was going to be created instead. You could take over that proposal if you want to work on it.
There is in existence sets of intelligent LEDs known commonly as NeoPixels but more properly as WS2812 and similar numbered devices. These LEDs have extremely intricate timing requirements and can not be natively driven by OS's that have pre-emption capabilities such as Windows and Linux. The Raspberry Pi for example can not drive them directly. There are Arduino and ESP8266 libraries that can.
What this issue suggests is the creation of a new protocol extension to be able to drive these LEDs. To set the color of an LED, we send in 24 bits of information. 8 bits for the red, 8 for the green and 8 for the blue. Since one can daisy chain these LEDs together, the suggestion is for the protocol to take as data the following:
2 bytes - count of LEDs - allowing up to 65535 (we do have chains > 255 so 1 byte is insufficient)
3 bytes of RGB data * count of LEDs
If we believe that this notion has merit and would notionally be accepted as a submission ... then I for one will be happy to go to the next level and write up a detailed
neopixel-proposal.md
file. However, before I spend time on that, I wanted to get a "pulse" on the acceptability of such a submission. If it holds no merit or is otherwise outside the strategy of Firmata then that will be that.Neil
The text was updated successfully, but these errors were encountered: