Difference between revisions of "Driving 8 WS2811 strips in parallel with an 8Mhz AVR"
From Just in Time
(Created page with "During a very short brainstorming session with Vinnie (where Vinnies part of the conversation consisted of mentioning that he had expected an 8-channel paral...") |
m |
||
| Line 5: | Line 5: | ||
We expect to use this technique in a number of POV applications (spinning globe, anyone?) | We expect to use this technique in a number of POV applications (spinning globe, anyone?) | ||
| − | The code is below. This is definitely simpler than the [[Driving the WS2811 at 800 kHz with an 8 MHz AVR|single-channel version]], but the single channel version had the advantage that the RGB (or rather GRB) values could stay in memory as such, without transposing. | + | The code is below. This is definitely simpler than the [[Driving the WS2811 at 800 kHz with an 8 MHz AVR|single-channel version]], but the single channel version had the advantage that the RGB (or rather GRB) values could stay in memory as such, without transposing. In this picture, as with the single-channel version, the ''NOP''-instructions have been omitted for readability. |
[[Image:8-channel ws2811.png]] | [[Image:8-channel ws2811.png]] | ||
Revision as of 01:34, 25 May 2013
During a very short brainstorming session with Vinnie (where Vinnies part of the conversation consisted of mentioning that he had expected an 8-channel parallel version of the WS2811 driver) it became apparent that it should be possible to drive 8 WS2811 led strings in parallel from one AVR. This allows a single 8Mhz AVR to output at a speed of 266666 RGB LED values per second, or 10000 LEDs at a framerate of 25/s.
Doing this requires that the LED data is transposed in memory, i.e. that the first byte contains the first 8 bits of the channels, the second byte the second 8 bits, etc. I'm currently working on a way to efficiently transpose the bytes in-place but there are many applications for which it is fine to have the data pre-transposed in memory ("bitmap-like" applications can have their bitmaps transposed).
We expect to use this technique in a number of POV applications (spinning globe, anyone?)
The code is below. This is definitely simpler than the single-channel version, but the single channel version had the advantage that the RGB (or rather GRB) values could stay in memory as such, without transposing. In this picture, as with the single-channel version, the NOP-instructions have been omitted for readability.
