On Nov 25, 2005, at 3:39 PM, Olin Lathrop wrote: >> The program works and everything looks great until you let it run for >> awhile. Then things start getting out of sync. I am using the osccal >> value for each device. While I didn't expect perfect synchronization >> I >> had hoped it would last more than a few minutes. > > Your expectations were unreasonable. Let's say they advance to a new > state every 500mS. If the two oscillators are off from each other by > 1%, then they would go thru a complete beat cycle every 100 flashes or > 50 seconds. That means they would be maximally out of sync in 25 > seconds from starting in sync. > Olin's right (as usual.) It's more that small variations in speed lead to getting far out of sync very quickly than that the pics are further out of sync than they should be... You should be able to fix this design by having one of the PICs output a short synchronization pulse on one of the output leads, and reading that on the other part via the (presumably unused) input only pin. This "sync pin" can be shared with an LED; code would look a bit like: Masterpic: changepattern: call setsync call delay500us call newpattern ; newpattern need not have sync set. call delay goto changepattern Slavepic: changepattern: call waitforsync call delay500us ; not really needed, but... call newpattern goto changepattern I guess detecting the sync pulse on a line regardless of it's prior state during the "lit" phase could be slightly tricky. You really want to change for a change of state rather than any particular state. You should only have to add one wire to your design... Um. I have a design and PCB that drives 20 leds from 8pin micros; either an attiny11 or pic12f style (theoretically; only the tiny11 version has been built.) "Charlieplexed" LEDs. Let me know if you'd like to look... BillW -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist