Driving the WS2811 at 800 kHz with an 8 MHz AVR

WS2811 LED controllers are hot. HackaDay has mentioned them three times in the last two months. Reason enough to order a WS2811 led string on ebay and start researching.

Normally I'd go straight to the datasheet and start working from there, but in this particular case the datasheets are [www.nooelec.com/files/WS2811.pdf not so very informative]. Luckily, the HackaDay links provide some excellent discussions. This one by Alan Burlison is especially helpful. That article not only explains in great detail why a library like FastSPI isn't guaranteed to work, but it comes with working code for a 16Mhz AVR that appears rock solid in its timing. Another good source was a post by "Cunning_Fellow".

Small problem: I didn't have any 16Mhz crystals on stock, so I ordered a few, on ebay again and sat back for the 25 day shipping time to pass. 25 Days is a long time. The led strip had arrived and was sitting on my desk. 25 Days is a really long time. Maybe it could work off an AVR on its internal 8Mhz oscillator? It would be a lot of work. But 25 days is a very, very, long time.

So, that is how I got to sit down and write my 8Mhz version of a WS2811@800Khz bit banger. The challenge is of course that I have 10 clock cycles for every bit, no more no less, and 80 cycles for every byte, no more no less. I wanted the timing to be as rock-steady as Alans, give-or-take the imprecise nature of the AVR internal oscillator.

You can see the result below. For the impatient: example source code can be found here. The assembly is absolutely unreadable, but I explain everything as best as I can after the video. I'll also explain how a spreadsheet came to be the best IDE for this type of coding.

The challenge

For a full description of how to communicate with a WS2811, please refer to either Alans page or the datasheet. In summary, the microcontroller should send a serial signal containing 3 bytes for every LED in the chain, in GRB-order. The bits of this signal are encoded in a special way. See the figure below.

This image shows a sequence of a "0" followed by a "1". Every bit starts with a rising flank. For zeros, the signal drops back to low "quickly" while for ones the signal stays high and drops nearer the end of the bit. I've chosen the following timing, in line with Alans observations and recommendations:

• Zero: 250ns up, 1000ns down
• One: 1000ns up, 250ns down

Giving a total duration of 1250ns for every bit, or 10μs per byte. 1250ns means 10 clock ticks per bit. That is not a lot. A typical, naive implementation would need to do the following things at every bit:

1. determine whether the next bit is a 1 or a 0
2. decrease a bit counter and determine if the end of a byte has been reached, if at the end:
   1. determine if we're at the end of the total sequence
   2. load a new byte in the data register
   3. decrement the byte counter
   4. reset the bit counter
3. jump back to the first step

Oh yes, and that is of course in addition to actually switching the output levels.

All of that does not fit into a single 10-clock time frame. Luckily, it doesn't have to: why not, instead of having a 10-clock loop over one bit, use a 20 tick loop over 2 bits? That is the central idea behind the code: at the cost of extra program space, create a sequence of assembly instructions that falls into 4 different states for every possible two-bit combination, instead of 2 states for every possible bit value. As it turns out, adding the end-of-byte and end-of-data criteria increases the number of states to 10.

Defining the puzzle

Juggling with so many states, jumping from one to the other without introducing phase errors turned out to be interesting. I spent a couple of lonely lunch breaks and several pages in my little (paper!) notebook before I even figured out how to describe the problem. When a notation became clear, however, the going was easy enough and this exercise turned into one of the nicer puzzles. Because there is no way I can relate the amount of work that went into solving the puzzle, here comes the full code in the notation system of my choice: a spreadsheet:

<to be continued>

{{#set: |Article has average rating={{#averagerating:}} }} {{#showcommentform:}}

{{#ask: Belongs to article::Driving the WS2811 at 800 kHz with an 8 MHz AVRModification date::+

 | ?Has comment person
 | ?Has comment date
 | ?Has comment text
 | ?Has comment rating
 | ?Belongs to comment
 | ?Comment was deleted#true,false
 | ?Has comment editor
 | ?Modification date
 | ?Has attached article
 | format=template
 | template=CommentResult
 | sort=Has comment date
 | order=asc
 | link=none
 | limit=100

}}