This page has the (overtaken by events) design info for controlling my old H-bridges with a PIC. It may still be useful someday; perhaps on another robot, or as a drive for some other kind of servo.
PIC software (servo.asm) to control 4 R/C servos from a SPI-like interface. Original Source is Mike Underhill's page
Microchip (PIC) web site: http://www.microchip.com/
| Back to plan B, for the mean time. A little web searching for suitable PIC software (I have the old PICstart Plus development kit and programmer), and choosing a processor (16C84, because that's what I have in the box), and we are off and running with the design. A block diagram of the general strategy is to the right (click to get full sized dwg as a GIF, or the Visio drawing). | |
The 16C84 has 12 bits of I/O, 4 on Port A, and 8 on Port B. I'll use Port B to drive the H bridges, and A as an interface to the Rabbit (or whatever). The basic control scheme is to reset the PIC whenever you want to change, blast the command bytes in, and then the PWM starts up. The PWM timing scheme is to define the timing in terms of a pair of numbers for each channel. The first (A or C in the diagram below) is when to turn the motor ON, the second, to turn the motor off. The software just counts from 0 to 255 (and loops back..), and when the count is equal to the number, the output pin to the H-bridge gets changed. Which pin gets changed is determined by the mode of that channel.
There are several possible modes for a channel, established in the mode byte:
The lower transistors are left on to allow circulating currents to flow when the upper switch turns off. As a side effect, if we want to rebuild the bridge with all the same kind of transistor (P or N channel), it makes the drivers easier on the high side because they don't need as high a switching rate.
Finally, there is a delay count byte, which is used to slow down the switching by spinning in a loop for a corresponding count before incrementing the pwm counter.
This scheme allows you to program the "on" time for the two sides to be non-coincident, which reduces the peak current drawn from the batteries. At some future time, it might be useful to put some dither into the loop to spread the PWM generated noise over a broader band, which will make it acoustically quieter. For now, everything will be at harmonics of the basic loop count, and I suspect that it will definitely "sing".
So, the total command message is 6 bytes (we don't need this many bits, but, it's easier to round up). If we punch them out from the rabbit at 100 kbit/sec, it will take 480 usec to send all the bits to the PIC. Presuming a typical loop update rate for the drive motors of around 10 Hz, the motors will effectively be "off" for about 0.5% of the time.