setLED(uint8 R, uint8 G, uint8 B)


 

I've been mucking around with these guys while in search of an elegant LED solution for my light, http://www.adafruit.com/datasheets/WS2812.pdf

 

images.jpg

 

They are reasonably well known in the arduino/wearable electronics community and there's some assembler code floating about to drive them on an AVR. The reason assembler is needed is that they are a driver and RGB LED in a single package, controlled by a single manchester-esque encoded data stream, running at ~800kHz. The timings are pretty specific and the often low operating frequencies used by arduinoists just won't cut it under normal circumstances.

 

I figured the psoc4 might be an ideal platform to drive these leds, although my solutions works it could be implemented far more elegantly ie. in HDL where the encoding could be done in hardware without the resource hit, anyway it's a bit of a hack as I mainly wanted to investigate the operating voltage characteristic of the LEDs and just needed something that worked, should I end up using them I'll definitely being learning the intricacies of building verilog components in Creator... They are attractive otherwise for this project in that they would serve well for the dual-mode operation (ie. front white LED, rear RED LED), a small array of them would be light on IO - they are chained, so a single data line can drive as many LEDs as you have memory resources and refresh rate desire to serve. The downside apart from the voltage rating may be that they simply aren't bright enough.

 

led_drive_output.jpg

led_drive_waveform.jpg

 

As you can see in this grab the 3rd trace down show an encoded 0xFF, followed by a 0 byte. The timings of the LED allow for a 1.2uS period to be divided in to three 0.4uS segments, essentially representing what can be thought of in order as the start bit (1), data bit, and stop bit (0) for each bit of the 3 bytes that specify the RGB level of the LED. The frequency divider in the above circuit provides a signal for the dead time after the data stream (50uS) to allow the LED(s) to latch.

 

 

Here's the result. I'm not quite convinced that overall the light output is sufficient, they seem to run ok down below 3V but with some output loss, nominally they are 5V, so I think some extra power circuitry would be needed to drive them consistently throughout the discharge cycle of the battery. I'm going to continue on with some testing of more traditional LEDs and PWM, but may come back to these..

 

Anthony