Hi all,

As I've alluded to in a few other posts, I'm working on controlling
the WS2812 LEDs. I am interested in them because they are an RGB LED
with built in control electronics. Adafruit sells them as NeoPixels.
They rely on a serial data stream to load their internal PWM
registers. I think they could be extremely useful as indicator LEDs as
they only require 1 port pin, but can be any colour I choose. Plus,
they are chainable, so adding more LEDs doesn't require any more port
pins.

I'm using this as an intro to programming in C. At the moment I'm
using a PIC18f25k22 running at 64MHz (16MHz x4PLL). I'm using the MSSP
in SPI mode to control the LEDs, using some clever ideas I picked up
here: https://www.insomnialighting.com/products/rgbsmdws2811.html .
The super quick summary is that we're ignoring the clock line, and
using two different 8 bit numbers to approximate the timing that the
LED is expecting when squirted out the SDO line. It's pretty clever,
and also frees us from having to sit in some tight timing loops and
toggle the line manually. It does lead to a bit of confusion though as
each byte that we're transmitting out of the MSSP is actually one bit
to the LEDs.

The exciting thing is that I have actually managed to get my code to
work. I must admit, I'm a little shocked myself. However, it is
running in a main loop, with no interrupts. My ultimate goal is to
devise a library of code that can be included in future projects, and
runs using interrupts so that it isn't hogging the entire processing
time on the chip. This will be a bit tricky, as the timing that the
LEDs require is rather tight. What I'm looking for is advice on how I
should be proceeding in splitting the code up to move bits of it into
the ISR.

My original plan was to start using the SSP interrupt flag. So I'd
load the buffer, exit out of the ISR, then wait for another interrupt
and load the next bit. I've done a bit of math though, and I'm not
sure if that's going to be possible. The chip is running at 16MIPS, so
an instruction takes 62.5nS. At the data rates I'm using, each byte
sent by the SSP takes 2uS. This means we've got less than 32
instructions to finish up in the ISR, exit, do something else, then
re-enter for the next byte. As I haven't coded any of this yet, I'm
not even sure if the latency between the interrupt flag being set and
managing to get to the ISR, figure out what's happening, and load the
next byte will be too much for this to work. I don't believe it will,
I just don't know for sure.

Another option would be to send an entire LED's worth of data (24
bits, 8x RGB) before exiting the ISR.

I'm honestly not too sure which way to go. I'd like to keep this
simple and reliable, but I also want the library to be expandable. If
the target is a chain of 30 LEDs, that will take significant time in
the ISR that's probably not too cool.

I've also considered using interrupt priorities, having most of my
interrupts as low priority, and the SSP interrupt flag as high
priority. Not too sure about that one either.

I'd be happy for any and all discussion and advice!

Thanks,

Josh
--=20
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
        -Douglas Adams
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.