Cool Chip: 30 MHz ARM Cortex-M0+ 32-bit MCU by NXP

The LPC800 series from NXP is a sweet little Cortex-M0+ MCU family that's available in 20, 16, and even 8-pin (DIP) packages. It's a shame the 8-pin isn't available in an SMD form factor, but hey - it's still a 32-bit MCU in 8 pins.

We'll just have to keep this sucker in mind for future projects. :-)

Fun with RGB LED Strips - Part 9: Full Reel Revisited

My power supply came today (a TDK-Lambda LS200-5, $58 from Mouser), so I was able to try out the full 5 m strip at full brightness. These suckers are quite impressive! Unfortunately, my DMM has a 10 A limit for current, so I'll have to take things into work with me one day to measure draw.

When firing up the strip at full brightness for the first time with the new supply, there was a noticeable loss of output toward the unconnected end of the strip. The way I'm powering the strip through a breadboard may be part of the issue, though I've seen reports of similar behavior online. For now, I've got supply and ground connected at both ends and performance is just fine.

Another obligatory video follows. Hey, at least it's not my dog. Well, it wouldn't be my dog, since I dislike dogs and don't own one... but you get the idea...

Sadly, playtime's over. I now have no excuses to avoid digging into audio. Oh well... It'll be fun once the code's done. :-)

Fun with RGB LED Strips - Part 8: Driving a Full Reel

Today I got a full 5 m reel of the SMD5050 LED strips I'd been playing with, so I decided to try it out. Unfortunately, I can't really drive it at full intensity, since the power supply I ordered hasn't come yet. Each full 5 m strip (64 LEDs / m) supposedly draws a maximum of 19.2 A or 96 W (all RGB channels at max), though it's not yet clear to me that that number is correct. So I've got a 40 A 5 VDC supply coming, which will be adequate for driving two full strips.

The theoretical maximum current number is based on the SMD5050 per-LED max current of 20 mA:

20 mA/channel × 3 channels/LED × 64 LEDs/m × 5 m = 19.2 A

I'm suspicious of the actual power consumption because I was able to drive my 1 m strip white without a noticeable drop in brightness, but my current power supply delivers only 1.5 A. I'll throw a meter inline with power when I get a chance to see what's actually going on.

At any rate, even at a reduced brightness level, it looks pretty. :-)

Here's a 'scope picture showing the SPI data activity:

At an 800 KHz bit pattern rate (effective bit rate for the WS2811, not the SPI bit rate which is 4x faster), each single data transmission for one 5 m strip takes 9.6 ms:

(1 / 800 KHz) s/bit × 8 bits/channel × 3 channels/LED × 64 LEDs/m × 5 m = 9.6 ms

That means I can run things at an update rate of 60 Hz with no issue whatsoever.

Fun with RGB LED Strips - Part 7: Multiple Strips

While I'm waiting for a new strip to arrive (one 5 m reel), I thought I'd test out multiple instances of my driver. I don't do the whole "delayed gratification" thing very well, so I cut my 1 m strip in half.

It works quite nicely (first time!):

So that's SPI1 and SPI2 running simultaneously (DMA). I'm hoping that I'll have plenty of processor overhead to pull in audio through an ADC port, run an FFT on the data, and use the frequency domain data to drive the LEDs in interesting ways.

(Observant viewers may notice that the very first LED on the "lower" strip in the video (closer to the edge of the breadboard) appears not to be showing all colors. There's something odd going on, but it's neither the LED nor the strip itself - it stays associated with that second line when I swap strips. I'll have to have a look at the output on a 'scope when I have time.)

"NRZ" and Grains of Salt

Just a thought on nomenclature...

In the RGB LED strip project I've been describing, I'll use "NRZ" to refer to the zero and one waveforms sent to the WS2811, reflecting how the datasheet describes them. This is technically not accurate... The scheme they use is an isochronous self-clocking line code, but I'm not sure it really has a name. In some ways one could think of it as being a variation of Manchester encoding, though not quite.

Anyway, it's easier to refer to it as "NRZ", so deal with it. :-)

Fun with RGB LED Strips - Part 6: Color

(For purposes of discussion, I'm assuming 8-bit color channel values below.)

The canonical "scrolling rainbow" I showed in Part 2 used a very simple (and naïve) HSV-to-RGB converter to generate the RGB rainbow. However it wasn't very satisfying, because RGB values by themselves bear only a passing correlation with actual colors. If you have ever worked with digital photography or graphical design, you'll understand exactly what I mean. A given picture or image on your laptop's screen will probably look noticeably different on another screen (without calibration and the assistance of software meant to correct these things). An RGB value of 65, 0, 255 - a nice, satisfying violet color on my laptop - only communicates to the display device, "set your red output to 65/255 of its maximum output; turn your green output off; and turn your blue output all the way on." It says nothing about what the exact meaning of "red", "green", and "blue" is supposed to be, and puts no constraints on the linearity of each of those components when displaying values from 0 through 255.

As I have time, I think the next thing I want to do is to look into color representation schemes and figure out how to quantify the gamut produced by these SMD5050s, and also investigate perceptual color representation. I'd like to be able, say, to produce a rainbow wherein only the hue appears to change, but not the apparent brightness.

We'll have to see to what extent work and other aspects of life get in the way this week...

I'll leave you with one more bit of eye candy; this shows three separate intensity "waves" - one for each RGB channel - moving at slightly different speeds, with an update rate of 120 Hz:

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).