After clones and variations of the venerable WS2812, there finally seems to be a new RGB-LED with integrated controller that actually improves on several characteristics: The APA102, also known as “Superled”. There are two versions on the market, the APA102 and the APA102C, as shown below.
The WS2812 RGB LEDs with integrated controller are fairly successful devices that come in a variety of packages. Recently, similar devices by other manufacturers started to appear.
I managed to get my hands on a few samples of LEDs with PD9823 controller, courtesy of Soldering Sunday, and was able to subject them to more scrutiny. The manufacturer of the IC seems to be “BaiCheng”. You can find it in several LEDs with different package types. There is a single page “datasheet”, linked here, but little else is known to me.
The given timing values are, again, completely different from any other device. So are these really compatible to the WS2812? Only one way to find out: I used the same setup to extract the timing as described earlier for the WS2812. You can find the results below.
Atmels AVR ATtiny10 are surprisingly powerful devices that come in an extremely tiny SOT23 package with only 6 pins. The have 1kb of flash, 32 bytes of SRAM and use the reduced AVR core which only supports 16 instead of 32 register. It seems like Atmels idea of these devices is to use them as an advanced blinker, and to replace tiny logic circuits. But other people have shown that much more is possible. For example the noiseplug (video), a chiptune player, and a Simon Says game.
I previously used the ATtiny10 in the TinyTouchbutton, a touchbutton controlled light with WS2812 LEDs. This time I aimed higher: Is it possible to turn the ATtiny10 into a USB compatible device? My goal was to implement a subset of the little-wire functionality to control a WS2812 LED by USB. This takes 3 I/O lines, which is exactly the number of free pins on the ATtiny10.
Littlewire supports several functions to control WS2812 LEDs on arbitrary I/O ports. I simplified this to only supporting a single LED on a specific pin, however still retained protocol compatibility. This means that all the little-wire host-programs still work. The finished device can, for example, be used as an RGB indicator LED similar to the Blink(1).
My test setup is shown below. The ATtiny10 is almost the smallest part of the circuit. There are some discrete components on the rear-side of all PCBs, so do not be surprised about missing decoupling capacitors, zener diodes and resistors.
I previously reported on reverse engineering a candle flicker LED. My approach was to extract the “flicker” pattern from the input current variation and to deduce the algorithm from statistical analysis.
Reverse engineering the controller chip
Of course there is another, more involved, approach. And that is to reverse engineer the circuit directly from the die. Andrew Zonenberg from Siliconpr0n decapsulated and imaged the controller chip from one of my LEDs. You can find his report here.
He managed to obtain very high-resolution optical microscopy images of the top-level metal. It turns out that the controller chip is manufactured in a relatively coarse CMOS process with one metal layer and 1-2 µm resolution. This is 1980ies technology. But of course, that is all that is needed for a circuit as simple as a flicker-LED.
There is a new addition to the popular WS2812 family of RGB LEDs with integrated controller: A 8mm through hole version. Right now they seem to be in pilot production stage. The only place that has them is Soldering Sunday where they are called PixelBits. My understanding is that they will also be available at the usual sources later this year. I got a couple of them to test for compatibility with my light_ws2812 library.
What’s pretty cool about these LEDs is that they are diffuse – no more blinding unidirectional light. This might be very useful for indicator lights. Furthermore, you can easily wire them freeform without a pcb. I see a lot of RGB LED cubes coming up…
After investigating the timing of the WS2812 protocol in the previous part, the question is now how to use this knowledge for an optimized software implementation of a controller. An obvious approach would be to use an inner loop that uses a switch statement to branch into separate functions to emit either a “0” symbol or a “1” symbol. But as it is often, there is another solution that is both more elegant and more simple. Continue reading “Light_WS2812 library V2.0 – Part II: The Code”
WS2812 LEDs are amazing devices – they combine a programmable constant current controller chip with a RGB LED in a single package. Each LED has one data input and one data output pin. By connecting the data output pin to the data input pin of the next device, it is possible to daisy chain the LEDs to theoretically arbitrary length.
Unfortunately, the single-line serial protocol is not supported by standard microcontroller periphery. It has to be emulated by re-purposing suitable hardware or by software timed I/O toggling, also known as bit-banging. Bit-banging is the preferred approach on 8 bit microcontrollers. However, this is especially challenging with low clock rates due to the relatively high data rate of the protocol. In addition, there are many different revisions of data sheets with conflicting information about the protocol timing. My contribution to this was the light_ws2812 library V1.0 for AVR and Cortex-M0, which was published a while ago. A V2.0 rewrite of the lib was in order due to various reasons. And, to do it right, I decided to reverse engineer and understand the WS2812 LED protocol to make sure the lib works on all devices.
Let’s reverse-engineer a LED, pedantic mode.
Lately, cheap electronic candles seem to be everywhere. I never paid much attention to them until recently it came to my attention that they actually use a special type of light emitting diode with integrated “candleflicker” controller. Now this is something different – who doesn’t like obscure LEDs? Half an hour later I had managed to score a bag of candleflicker-LEDs from the chinese manufacturer.
Very nice, you can not do that with real candles. But the interesting part is of course: How do they work? Considering that they literally sell for a few cents a piece, there can not be very expensive electronics involved. This raises another question: Are these cheap LEDs really worse than all the self-made microcontroller based LED-candles around the web?