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

Fun with RGB LED Strips - Part 4: STM32F4xx Clock Configuration

(Details of RCC configuration can be found in Section 5, "Reset and clock control (RCC)" in "RM0090 - Reference Manual - STM32F405xx, STM32F407xx, STM32F415xx and STM32F417xx advanced ARM-based 32-bit MCUs", available for download from ST Microelectronics.)

To arrive at a SPI bit rate of 6.4063 MHz:

1) Set M, N, and P to yield a main PLL frequency of 102.5 MHz.

VCO(in) = HSE / M, and must be 1 ≤ VCO(in) ≤ 2 MHz; set M = 4 to yield (HSE is an 8 MHz crystal):
VCO(in) = 8 MHz / 4 = 2 MHz

VCO(out) = VCO(in) × N, and must be 64 ≤ VCO(out) ≤ 432 MHz; set N = 205 to yield:
VCO(out) = 2 MHz × 205 = 410 MHz

PLL(general) = VCO(out) / P, and must be PLL(general) ≤ 168 MHz; set P = 4 to yield:
PLL(general) = 410 MHz / 4 = 102.5 MHz

Note that PLL(general) is SYSCLK.

(The value of Q, which divides VCO(out) for the USB OTG FS, SDIO, and RNG clocks, doesn't matter. I set mine to 9 to yield a rate of 45.6 MHz so that I could use the RNG if I chose, in which case the RNG clock must be ≤ 48 MHz.)

2) Set the HCLK (for AHB) divisor to 1 to yield an AHB clock of 102.5 MHz.

3) Set the PCLK1 (for APB1) and PCLK2 (for APB2) divisors to 4 and 2, respectively.

Constraints: max PCLK1 = 42 MHz; max PCLK2 = 84 MHz.

PCLK1 = HCLK / 4 = 102.5 MHz / 4 = 25.625 MHz (low speed APB1 bus clock)
PCLK2 = HCLK / 2 = 102.5 MHz / 2 = 51.25 MHz (high speed APB2 bus clock)

4) Set the SPI peripheral baud rate prescaler to 8 (for SPI1, on the high speed APB2 bus) or 4 (for SPI2 or SPI3, both on the low speed APB1 bus).

SPI baud rate = PCLKn / prescaler

For SPI1:
SPI baud rate = PCLK2 / 8 = 51.25 MHz / 8 = 6.4063 MHz

For SPI2 and SPI3:
SPI baud rate = PCLK1 / 4 = 25.625 MHz / 4 = 6.4063 MHz

Fun with RGB LED Strips - Part 3: WS2811 Timing

The WS2811 is a nice little constant-current three-output PWM LED driver with a single data input and one data output for chaining. After a reset condition (more on that in a moment), each device will look for and interpret 24 bits of data, 8 bits per color component (sent MSB first), with each bit being sent as a hi/lo NRZ waveform with specific timing; once a device has read 24 bits, it then mirrors all subsequent data on its data out line. A reset waveform (low input for at least 50 µs) causes each device to update its RGB PWM outputs according to the RGB triplet it just read; the PWM state of these outputs stays as programmed until the device receives another RGB triplet and reset condition.

According to the WS2811 datasheet, the low-speed 400 KHz NRZ waveform timings are as follows (we'll ignore rise and fall times and permissible slop for now and just focus on idealized timings):

The datasheet does not give explicit timings for the high-speed 800 KHz data rate, but rather just indicates that all parameters are half of the given 400 KHz values except for the reset condition minimum duration of 50 µs (though it's not clear whether the "half" also applies to the parameter tolerance of ± 150 ns). Therefore the high-speed 800 KHz timings will be:

I didn't want to bit-bang since that's not very portable. The best approach seemed to be to try to make use of a serial peripheral. Speeds on the USARTs aren't as high as would be required, so I decided to look at SPI instead. The most logical approach would be to treat each NRZ pattern as an 8-bit byte and then attempt to come up with a SPI peripheral clock that would provide edges as close to the nominal timings as possible. The NRZ pattern period at 800 KHz is 1.25 µs; 1/8 of that period is 156.25 ns which is a bit rate of 6.4 MHz. That would be my target.

The processor on my Discovery board is an ST Microelectronics STM32F407 and has an 8 MHz external crystal. The STM32F4xx family contains a reasonably sophisticated clock generation scheme (the RCC subsystem); after a little calculation, I determined that I could configure the clocks to provide a 25.625 MHz SPI peripheral clock, and divide by 4 to yield a SPI bit clock of 6.4063 MHz, or a bit timing of 156.10 ns.

Here's a comparison of the edges at this bit rate with the desired 800 KHz NRZ pattern edges:

Two of the SPI bit edges align with the ideal NRZ edges with errors of 62 and 24 ns. This should let me generate NRZ hi and lo times that are within the tolerances given in the WS2811 datasheet, even if those tolerances are divided by 2 for 800 KHz operation (± 75 ns).

According to the choices of edges above, to generate a '0' pattern, I'll have to send two high bits followed by six low bits (byte value = 0xC0); to generate a '1' pattern, I'll send four high bits followed by four low bits (byte value = 0xF0).

This means that for every 24-bit RGB triplet, I'll send 24 separate bytes - one for each bit in the triplet. Note that since the patterns both contain multiples of 2 bits' worth of ones and zeros, I could optimize memory usage by halving the SPI bit rate and sending two NRZ bit patterns at a time (one in each nybble of the transmitted SPI byte); to get things going, however, I decided to defer making this optimization until later.

Before continuing with implementation, I'll make a separate post describing the STM32Fxx clock configuration for anyone who might be interested.

Fun with RGB LED Strips - Part 2

This evening I finally managed to successfully drive my LED strip at 800 KHz. Here's the obligatory moving rainbow disco video:

The WS2811 is, let's say... particular... about its NRZ edges at 800 KHz. My first shot at selecting a SYSCLK frequency and dividing down from it worked brilliantly for 400 KHz (literally - these SMD5050s are quite bright), but resulted in mostly white light when I cut the divisor for 800 KHz. I'll describe clock configuration in a later post.

In the video above, I'm initiating the SPI DMA at 60 Hz by waiting on a timer. For kicks, I also tried waiting on DMA completion. It looks like this (the effective update rate is somewhere a little above 500 Hz):

Here's a 'scope screenshot showing the timing of the associated data bursts (at the above 'fast' rate):

Here are two screenshots showing individual NRZ bits; first the '0' pattern, then the '1' pattern:

Next up: driving the WS2811 and clock configuration... With luck, tomorrow. :-)

Sodium Acetate and Kitchen Science

A couple of weeks ago, I had an occasion to dig out my flask of sodium acetate I'd made a few years ago (I wanted to see if I could make it from scratch and get it to crystallize properly). If you're not familiar with it, sodium acetate is the chemical in "phase change" heating pads - the ones that have a clear liquid inside, and that solidify and release heat when you "click" a little metal disc in the corner of the pad; they are "recharged" by boiling the pad until the white solid inside becomes liquid again.

I'd made an Instructable about it - it's amusing to read. It was an interesting diversion, though I was a little concerned about having a neighbor see all of the glassware in my kitchen through the window and report me to the police, suspecting I was running a meth lab.

Fun with RGB LED Strips

I've had an interest in solid-state light sources - and all the fun things one could conceivably do with them - for some time now. Recently, I've actually had enough of a break in my absurdly insane work and home schedule to permit me to dip a pinky toe in the waters.

I've had my eye on the WS2811 from World Semi for a little while, and more recently the SMD5050 RGB SMD LED which incorporates a WS2811 in-package.

So I finally broke down and bought an RGB LED strip to give them a go (just a meter to start).

I had also recently acquired a Discovery Kit from ST Microelectronics and, since I work with the STM32 family quite a bit where I work, I decided I would use that as the driver platform (it features an STM32F407 microcontroller). I also wanted to write my own code for it - it's more fun that way. :-)

So far, I've had just enough time to get the basics of the driver working.

Yes, I know - the 'scope's a dinosaur. I haven't bothered to buy anything newer because I have access to excellent equipment at work. Besides which, when I do drag it into work with me (much of my equipment finds its way there at various points in time), I can be assured that it won't walk off. No one wants to use a 60 MHz 'scope. :-) Unfortunately, it's barely sufficient for this application, and while I'm getting the timings tweaked I'll probably have to bring things in to work with me for a bit.

Since driving a WS2811 isn't a straightforward process, I figured I would share my observations and perhaps my code as well, as I'm working on this project.

Now if I can only find another two or three hours of uninterrupted free time...