Fun with RGB LED Strips - Part 5: Memory Optimization; SMD5050 Data

Memory Optimization

First off, last night I took a moment to refactor code to transmit two NRZ bit patterns per SPI byte (the memory optimization I mentioned at the end of Part 3). That worked just fine, halving the memory requirement for the buffer used to hold outgoing pattern bytes.

All timings I've discussed so far still apply except for SPI bit rate. The SPI baudrate is now 3.2031 MHz, half of what it was. To achieve this, the SPI baudrate prescaler must be set to 16 (for SPI1) or 8 (for SPI2 or SPI3).

Now, instead of transmitting 8 SPI bytes (8 NRZ bit patterns, each 8 bits wide) per one data byte to be sent to the WS2811, I'm transmitting 4 SPI bytes (still 8 NRZ bit patterns, but only 4 bits wide).

This figure illustrates the transmission of a zero NRZ bit pattern followed by a one pattern:

SMD5050 Data

The SMD5050 contains an integrated WS2811 with high-speed mode (800 KHz) enabled. The only real 'gotcha' is that the RGB LED chips in the package are NOT all connected to the appropriate WS2811 RGB outputs: instead, R and G are swapped. I imagine some EE goofed, bleary-eyed from an extremely late night partying with a couple of hot assembly techs from manufacturing, and the blunder was not discovered until QA got their hands on a sample from the first million that came shooting off the line. At that point, of course, it'd be too late to do anything about it. (How does one say, "ooops, my bad," in Cantonese?)

Excepting the R/G swap, one can rely solely on the WS2811 datasheet (poor translation notwithstanding) to figure out how to get data to the chip. Here's the conceptual process:

1) Given a 3-byte RGB triplet, send 24 bits to the SMD5050 in G-R-B byte order, MSB first for each bit; send each bit using the '0' or '1' NRZ waveform;

2) Repeat (1) for each RGB triplet to be sent (corresponding to the number of chained SMD5050 LEDs);

3) After all triplets have been sent, hold the data line low for at least 50 µs before repeating the process for the next "refresh".

My implementation of the process goes like this:

In the Tx Data buffer, the single 0x00 byte header ensures that the data out line starts off low; the 21 byte 0x00 trailer ensures that the data out line stays low for at least 50 µs before any new data gets sent (this is the reset condition that causes all SMD5050s in the chain to update their PWM outputs to the RGB values they've just received and start looking for new data).