Actions

Difference between revisions of "Driving 8 WS2811 strips in parallel with an 8Mhz AVR"

From Just in Time

m
m
Line 5: Line 5:
 
We expect to use this technique in a number of POV applications.
 
We expect to use this technique in a number of POV applications.
  
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.
+
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.
 +
 
 +
One interesting aspect of this code: the decrement of the bit-counter (''SUBIW bits, 1'') is at the start of the loop, while the corresponding conditional jump (''BREQ finish'') is near the end. It wouldn't fit in any other way (without compromising the signal for the final bit) and it is only possible because none of the other statements in this loop affect the zero-flag. It just had to be...
  
 
[[Image:8-channel ws2811.png]]
 
[[Image:8-channel ws2811.png]]

Revision as of 10:29, 26 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. If your application has the data in rgb-format in memory, some transposition is necessary. Transposition is fairly easy if you've got twice the memory: just create the transposed data by reading and shifting the source data. Doing the transposition in-place, without requiring twice the memory, is more difficult and boils down to in-place matrix transposition. There are many applications, however, for which it is fine to have the data pre-transposed in memory ("bitmap-like" applications can have their bitmaps pre-transposed).

We expect to use this technique in a number of POV applications.

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.

One interesting aspect of this code: the decrement of the bit-counter (SUBIW bits, 1) is at the start of the loop, while the corresponding conditional jump (BREQ finish) is near the end. It wouldn't fit in any other way (without compromising the signal for the final bit) and it is only possible because none of the other statements in this loop affect the zero-flag. It just had to be...

8-channel ws2811.png