Better processing of a serial bitstream

[skimask]

I did the same thing awhile back, use an 8 pin PIC without a UART, ran RGB LEDs using PWM, tried to control/run them using serial input.
Problem is, it takes X amount of time to receive serial bytes using the software 'bit-bang' method, which invariably interrupts your PWM for the LEDs, causing the flickering.

My solution (and I'm sorry I can't give you the code I used 'cause I got paid a fair amount of money for it and the owner of that code is a tinkerer himself), using a 12F683, was to use the built in 8Mhz oscillator to run the TMR0 and use the overflow interrupt, this gave me a 7812.5Hz loop, which you could use to sample a serial input line using a 7812.5 baud rate. Well, that doesn't work too well because the bits have to be perfectly centered and everything.
So, I use a bit of multi-sampling, over-clocking, majority logic, whatever you want to call it, whatever it's really called...I don't know.
I knocked my transmitter baud rate down to 488.28125 (or at least as close to that as I could get it), and sampled the receive bit 16 times and I'd count the amount of time the bit was high and/or low and pick the higher number of the two.
The one special case is the initial 'start' bit. If all 8 bits ended up being a '1', then I'd continue to look for another 4 bits of high without any low in there anywhere. Same thing for the stop bits.
Basically, I made it up as I went along... It's kinda like bit-banging a serial port, but the program keeps running in the background.

Oh, and at the same time the TMR0 overflow would interrupt, after checking the serial input, I'd update the RGB PWM for the LEDs.
Worked out kinda slick...

Hope that gives you some ideas...

[SteveB]

How often do you need to send each slave a seperate RBG value? If most of your transmissions will have the same values for many of the slaves, you might try something along these lines. Use a 4 byte + 3 Byte string. The 4 bytes is used to address the slaves, each with their own individual control bit. The 3 bytes are the RGB values. Any slave whose bit is set in the 4 bytes will use the RGB values, others will ignore the data.

This would allow you to send a much smaller data packet, and the slave processing overhead would still be pretty minimal. Also, you could use the left over 7 bits (from the 4 byte group) to have a bunch of "commands" preprogrammed that the slaves could respond to accordingly.

The obvious downside is that if you need to have individual values for all 75 slaves it is much more data then what you've got.

Also, you might be able to dump the interrupt and just poll the RX pin. The master could hold this low (or high) for a period of time and the slaves can poll it. If it is in the correct state for a loop or two of the main loop, the slave jumps to the recieve and waits for the data. This would rid you of the need for the "junk" data. You would have to tinker with the timing to get all the slaves to respond reliably, but it should work well. With the above technique, you looking at about 7.3ms per data packet. 25 of them is 183ms, so a bit high if you have to update all of the slaves individually.

Just a couple of thoughts,
SteveB