Is there a canonical way to signal WS2811/2812 LED strip?

Question

The WS2811/2812 protocol is well-defined and hence the chip now seems to dominate addressable strip lighting products.

People have managed to use SPI and UART to control it, and someone even did it with GPIOs. But all of them never fail to comment on the relatively tight timing constraints it involves.

My question is, before these clever people came up with clever solutions to bitbanging this protocol, what was the canonical way to talk this protocol? Definitely something non-bitbanging, but also something that wasn't "abusing" existing hardware in a way that wasn't intended. I imagine some sort of hardware FIFO which loads up enough bits beforehand that the timing is not challenging to meet with Arduino on AVR, ESPs, PIC etc.

I have searched extensively and can only find clever libraries, no canonical/standard/straightforward hardware ideas/schematics.

Answer 1

The WS2811 protocol is relatively easy to generate. The different length pulses can be generated by monostables, or by a small counter clocked at a suitable rate. Given a byte for the desired light level, the byte can be clocked out bit-wise from a parallel to serial shift register.

The original designers of systems to control these LEDs would use just these components, jelly-bean prices and a few square inches of board for TTL or CMOS counters and shift registers.

Once controls for these needed to go into millions of units, so the designers were shaving pennies and size, those few parts could be compressed down into a tiny corner of an ASIC or FPGA that was running the rest of the system.

What the 'clever' people are doing with SPI, UARTs and bit-banging GPIOs is doing what all (most) engineers enjoy doing, showing that they can do something without the cost and area of the previous solutions.

IIRC, there are libraries to drive these things available for Arduino and the like, a de facto standard if ever there was one.

Answer 2

I would go so far as to not to describe any of the solutions that use typical microcontroller serial peripherals as being particularly clever. Yes, it's not the typical/intended usage of that peripheral, and you need to make sure you can keep feeding the peripheral without gaps, but I doubt that the designers of the WS2811/2812 protocol did not anticipate that this would be possible.

In fact, with just one data line, only cheap inaccurate sources in each device and no fancy PLLs, there are only so many ways to design such a one-pin protocol, and it will always involve some kind of pulse-width encoding. The WS2811/2812 protocol has the advantage that the receiver only needs to distinguish two different pulse lengths, for typical UART it's nine different lengths (i. e. number of bits).

The protocol could have been designed to be more accommodating to microcontrollers by having a way to pause and continue the transmission, but it wasn't. This is less of an issue with modern controllers anyways because we usually have DMA and multi-transfer FIFOs.

Answer 3

The timing protocol is not that unforgiving.

You can interrupt the data stream after each LED, as long as you don't reach the minimum time for a bus reset, because LEDs later on the chain have not even been taken out of reset at this point, so they have no timing reference.

Also, "long pulse/short pause for 1, short pulse/long pause for 0" is equivalent to "output 1 for the short pulse duration, then the bit value for the difference between both, then 0 for the remainder of the bit time", so you can realize this with a branch-free assembler fragment that has predictable timing if you disable interrupts.

Answer 4

I don't know if it is canonical, but many MCUs include an output port state machine feature that is perfect for straightforwardly generating these signals.

On the tinyAVR chips, these are called Configurable Logic Cells (CLC) and on the RP2040 chips they are called programmable I/O (PIO) blocks. They are straightforward to configure to directly generate perfect WS2812B signals - no clever tricks involved. Both of these chips specifically include these types of signals as examples of intended uses for the hardware.

And, for the record, it turns out that WS2812B protocol is not really that picky about timing (my article about WS2812B timing).