WS2812B Active LEDs.

[bigclive]

Isn't it staggering how fast the addressable LEDs have been evolving. With the WS2812B chip we have a single 5050 style package with just four pins. 5V, 0V, data in and data out. All you need to do is wire them in your preferred manner with a power bus, small decoupling capacitor at each chip and the data looped through, and you have a serially addressable RGB LED array.

 

And the price is now down to pence per pixel.

 

I love the fact that the onboard chip isn't a microcontroller, but is just a logic array of counters and shift registers with what appears to be a common timing clock. All data management along the string of LEDs is down to a series of counters that determine if the incoming data bit is a one or zero by duration, then uses that data to fill each pixels shift register in turn before passing the rest of the data down to the next chips in line after buffering it. Then another common counter on all the chips determines when the data for that string of pixels is complete by detecting a static data state above a specific duration, and shifts all the data to the outputs to PWM drive the LEDs via current limited outputs.

 

This means that you could theoretically have a line of chips of near unlimited length with the only limit being the speed of data refresh (frame rate) and the need to inject a fresh 5V supply with commoned ground to handle the current requirement.

 

The only negative side to this whole scenario I can see is the inevitable fires caused by dipsticks not comprehending the concept of dividing the 5V supply into easily current-protectable portions, the increasing use of programmable strips to create nauseous DJ lights shows and the tedious job of actually making nice content to display on the pixel arrays.

[timsabre]

I've done a few jobs with these and the timing of the serial data stream makes it a bit of a pig to produce. It's also relatively slow at 800KHz which does limit the string length if you want to keep a reasonable refresh rate.

 

I have done more stuff with the LPD8806 which uses an SPI-like interface with data and clock and controls 2 RGB pixels per chip, that will run at 33Mhz which gives much better possibilities.

 

I recently came across an interesting company called My Semi who are making pixel driver chips with built in auto-addressing DMX and various other goodies, quite useful if you need to cover a distance in between pixels or groups of pixels.

[timmeh2]

Hi

 

I too really like these family of chips and have used loads of them. Like Tim says I find the 2811's single clock speed a bit of an issue. On Arduino you've got to be pretty careful how you manage your overheads, whereas with the 4-wire 2801 you can get pretty screwy with your timing and it'll still work. I've also made a starcloth made with LPD6803 but didn't like them so well as they only offer 16bpp as opposed to WS's 24bit.

 

Got to love the Chinese though - the prices for pixels are absolutely stupid; You can get 10mm LEDs complete with driver on a PCB for as little as 40p/unit, and even cheaper if you buy them straight out of the factory.

 

They've got all sorts, there's RGB strips with 144 2811's per metre, 16x16 matrix on flexible PCB and soon they'll be moving to OLED so god knows what sort of things they'll be coming up with next.

 

My current fave product is the 30 and 45mm IP67 pixel. 12V so you don't need to worry about voltage drop as much, and they've got 3-6 2811s together in a diffuse package. Perfect for med-res outdoor signs and flashy-lighty bits of set.

 

Despite not being colour-corrected, the tolerances on the 5050 are now getting so tight that near-enough-as-dammit you can't really tell the difference between pixels, especially with a diffuser.

 

I really fancy just going over there and buying a container full.

 

All the best

Timmeh

[bigclive]

The timing of the single data line versions is rather merciless, but if the chips work as I think they do the actual timing will have a bit of tolerance, since the chips seem to determine whether a bit is a one or zero by a very simple time delay after the original change of state. Theoretically you can pause for assembly breath after each bit as long as you don't exceed the delay that causes the chips to shunt all the data to the outputs.

 

It still doesn't leave a lot of room for processing time if you're bit-bashing though. Unless your code was being really fly you'd need to use a video frame to store the whole block of data, and alternate between pounding it out and making any changes to the data at the end of each frame transmission.

 

I was tempted to go down the clock and data route, but I honestly see the WS2812 chips becoming the standard just because of the ease of manufacture and the extra estate on the strip for maximising the size of the power rails.

[timmeh2]

Hi Clive

 

Indeed! You don't have much room for maneuver, especially on 16Mhz ATMega-based solutions. I use Artnet with mine so a good proportion of the CPU time is taken up by servicing the ethernet card and processing packet data. My bit-bashing code is written in assembler as the compiler isn't the most efficient and has a real tendency to stick it loads of unnecessary NOP instructions for no reason which just chew clock cycles. The good thing about the WS' 24bit data format is that it's exactly the same as whats coming in. My code will wait for the whole DMX packet to arrive and then spit out the data on a per-frame basis.

 

One of the key mistakes I see a lot of people doing is trying to use a timer to maintain the refresh rate. It simply doesn't work, as using a timer is extremely expensive in terms of CPU time. Using a timer can also cause issues with half-frames being displayed and other sync problems.

 

With 100-or-so pixels I can get 30-35fps which is good enough. The only limitation with Arduinos is that they won't work well with a multi-universe stream as the card just cannot keep up. That's where Pi comes in. If I'm feeling really suicidal one day I might try to port the Artnet handler to assembler and see what happens.

 

All the best

Timmeh

[gyro_gearloose]

The only limitation with Arduinos is that they won't work well with a multi-universe stream as the card just cannot keep up. That's where Pi comes in. If I'm feeling really suicidal one day I might try to port the Artnet handler to assembler and see what happens.

Have you considered using a Propelllor chip? In these days of the ubiquitous Arduino and Raspberry Pi, the Propellor is often overlooked which is a shame as its quite a powerful chip. There's a project called the Propcontroller which allows you to control all sorts of things via DMX or Ethernet (Artnet, sAcn, and RDM). I've found a Propcontroller forum over on the DIYChristmas forum, of all places! I haven't yet had a chance to look at the code, but I definitely will be doing so when I get some spare time :)

[Dmills]

The *RIGHT** way to do this is with a very modest fpga, they are good at things like this.

 

You can even implement a simple minded tcp/ip (or, even easier) udp stack as a hardware state machine and they ususally have enough block ram to store a frame buffer at the sorts of resolutions needed for led pixel displays.

 

Plenty of little fpga boards out there for not much cash.

 

Regards, Dan.

[bigclive]

I suppose that does make sense. Especially given that the LED chips themselves are basically a logic array. I'm not an expert in FPGA programming, but I guess it would be a series of shift registers just loading data out of the memory in parallel and then banging it out to the LEDs.

[dbuckley]

Have you considered using a Propelllor chip? In these days of the ubiquitous Arduino and Raspberry Pi, the Propellor is often overlooked which is a shame as its quite a powerful chip.

 

Prop is the chip of choice for this kind of applciation, in my opinion. So much less brainache to program for concurrent activities than other chips. And fast enough.

 

Having said that, Paul Stoffregen is doing lots of fun things with pixels using his Teensy boards, see [link], for those of an Arduino bent. I must confess, I do like the Teensys, even though I've done little more than play with them.

[bigclive]

That's the first time I've realised that the propellor chips are actually dedicated chips with multiple processors sharing common memory. For some reason I thought they were just another version of the "program PICs in BASIC" type of system. I'm not sure why I thought that.

 

So that does suggest a dedicated processor for banging data out while others do the fanciful visual stuff and bump it into the common memory.

 

But this doesn't quench my desire to implement a series of very random visual effects using the most minimalist bottom-end processor I can squeeze the code into.

[timsabre]

But this doesn't quench my desire to implement a series of very random visual effects using the most minimalist bottom-end processor I can squeeze the code into.

 

I've done it on an 8-bit Atmel mega, the main problem is you need quite a bit of RAM as a frame buffer, which rules out the smallest devices.

[Tomo]

I'm bit-banging the WS2812B strings using timer-triggered DMA on an ARM, a technique that I first found suggested here: https://github.com/PaulStoffregen/OctoWS2811

[Edit] Just realised that's the same guy dbuckley linked to!

 

It has almost zero CPU usage - the CPU simply does the bitwise arithmetic to arrange the data in memory, then lets the timer and DMA hardware do the actual transfer so you can do anything you like during transmission with no effect on the timing.

 

This method is best for driving multiple strips simultaneously - my implementation does 8 strips (one byte DMA transfers).

 

It's RAM-heavy as you need 2 DMA transfers per bit along the length of the strip, but extra strips cost nothing until you need to go to a bigger DMA transfer.

- My implementation consumes ~11 kB for 8x 240-LED strips (which is about the longest I dare run in one go, powered both ends!)

 

Theoretically the technique will do up to 32 simultaneous strips, if the MCU has enough RAM in a single block to use 32-bit DMA words and the right GPIO pins!

 

You might want to take a look at the Freescale FRDM dev boards. Dirt cheap and good fun!