The algorithm was meant for a Processor with about 33 I/O lines and the
need for a fair amount of servos. On the PICFlyer I have dedicated an
entire PIC to control servos. The PWM/External circuitry method does work,
but requires external parts. I want to keep size/weight to a
minimum. The only external circuitry that may help is a schmitt trigger to
clean the signal, but not even that is required. If someone needs more
than, say, 20 servos on board an airplane, there must be enough power
availiable on board for another PIC. the remaning 13 I/O lines are for the
parallel communication/Expansion bus.
My solution for the "screwed up timing" problem was a simple sacrifice, the
interrupts on thededicated servo controllers are off-limits. I have simply
decided to use a 13 wire parallel communications scheme instead of serial.
The "controller processor" places an 8-bit data packet on the data bus, the
address of the "desired servo controller" on the 4-bit address bus, and
waits.
When the servo controller is not processing a pulse, the entire 8bit
package can be taken at once, then an ACK signal (the 13th data bus line) is
brought high by the servo controller to signal it has the data, and is ready for
more.
This and other communications methods can be used to eliminate timing
issues, allowing the interrupt code to live in peace. Bottom Line: No
Jitter. I have been playing with this code all day, it is great. I
am using a 4MHz 16C84 and I could easily do more but I am out of I/O
lines.
Note that this algorithm wasn't designed for 128 servos to be controlled by
one processor. (Geez that is way more than I ever hope to own)
External circuitry may require more brainpower than I am willing to
expend. What if the processor fails? 128 control points, gone. To
me, generating an interrupt once per mS is excessive. It simply depends
upon your application. I want a great way to control servos, in software,
and have a chunk of free time. That is what this code does.
I decided that even a realtime-controlled, model airplane does not need a
servo update of 50 times/sec. Thats means that every single pulse the
servo receives would be different! I can do exponental/differential
rates myself in software. Simple calculus/physics is all that takes.
Resolution, however, is more important. The Serial-Parallel servo
controller combined with a parallel communications bus is more than enough to
maintain a very fast thoroughput, well above 50x/s. Maybe this evening I will
draw up a servocontrol library.....
Anthony, KC5LHH