Driving WS281x RGB LEDs from an nRF51822

[Alex Shepherd]

Hi Guys,

I'm new to using the nRF51822 environment but I've used AVRs for years, so please be gentle...

I'm wanting to drive a strip of WS2812 RGB LEDs from an nRF51822 processor. Ultimately I want to control it over BLE but initially I need to drive the LED strip first.

Here's the WS2812 datasheet:

The WS2812 RGB LEDs have a single data line that daisy-chains between devices and it has bit timings of about 1.2us where a 0 bit is High for .35us and Low for 0.8us and a 1 bit is High for 0.7us and Low for 0.8us.

One implementation on the AVR's disables interrupts and uses hand coded assembler to generate the right bit timing. Another implementation configures the SPI port to generate the correct bit timings by sending different byte values such that the different 1's and 0's generate the desired waveform.

There's a cleaver implementation on the Teensy 3.0 board here: www.pjrc.com/.../teensy3.html that uses the OctoWS2811 library that uses DMA and some timers to clock out the bit streams for 8 LED strips in parallel from buffer in SRAM at almost no CPU overhead.

I like the idea of using DMA however, looking at the nRF51822 it doesn't seem to have this capability.

Any suggestions?

Regards

Alex Shepherd

[Ling LI]

Yeah the EasyDMA is for the RADIO block, not accessable from user code.

I have no experience with this serial protocol (of unnecessarily high speed and weired custom timing). I guess the SPI solution you mentioned might be a suitable choice for nRF51. Concerning CPU overhead, let's hope the controller doesn't need constant control signal under stable conditions i.e., having internal latch/memory to keep the state. Otherwiese it's too bad; you may need a small AVR dedicated to this uninteresting, busy task.

[Marc Nicholas]

From what I recall, this controller is like a big shift register and you shift you last pixel out of the MCU into the first physical pixel which shifts it into the next one etc. etc.

I seem to recall timing issues and that you might have to constantly refresh the data stream?

Just thinking out loud: I wonder if PPI could help out here?

-m

[Alex Shepherd]

Yeah, I've looked at this for hours and the SPI only has a fixed selection of bit rates and the BLE SoftDevice adds too much interrupt latency to be able to get around and refresh Timer Compare regs in time.

So I think I'll have to add an additional CPU (AVR ATTiny85 probably) to drive these LEDs.

Alex

[Eric Salem]

I have implemented a library specifically for controlling these WS281x's using NOP calls timed to work. However, I have not tested it with the softdevice enabled and have only tried up to 4 parallel strips of 10 LED's each.

Will report back after testing with softdevice.

[Bastiaan]

Ran a quick and simple test using the UART ble program to turn on a new LED at red for each serial packet collected and to turn off all LEDs on a write from the phone to the characteristic. Seems to run regardless of the softdevice running.

I have read into that makeshift SPI setup and seen the Teensy library, but again decided to implement my own NOP based library.

Sorry that I am not capable of sharing the code at this time.