Controller software
For those that just want the firmware download, we have:
- i2cpwm.asm (the main PIC assembly file)
- i2cpwm.hex (compiled HEX image)
- i2cpwm.zip (project files and testbenches)
Theory
There are two main tasks to be performed by the software: talking to the I2C bus, and setting the H-bridge outputs. The outputs need to be updated on a set schedule, so the PIC's timer is used to regulate it. The I2C bus is polled, and the PIC has no direct hardware support. This is why the maximum frequency is so low compared with I2C-native devices.
I2C implementation
The I2C implementation is fairly uninspiring; read the Philips I2C spec if you want to understand what's going on. It requires open-drain outputs for the bus lines. The PIC only has one (and I'd already attached it to a LED on the prototype). To simulate open-drain outputs, the PIC I/O's are tristated for a '1', and set as outputs (with an output value of '0') for a '0'.
Once the I2C code has received an entire transfer, it does some legwork for the H-bridge code. When a channel's PWM signal is high or low, a certain value is written to the output port. This is the mapping between command and H-bridge lines. Each channel has a pair of registers that set these high or low values. Depending on the command (forward, reverse, brake, coast), the I2C code will set up these register in advance, so all that the PWM code has to do is stick them on the output pins.
PWM implementation
The PWM uses a 'ratio' register for each channel to determine what fraction of the total time the PWM signal is 'high' for. On each iteration, a 'value' register is incremented. Its maximum value is the maximum PWM ratio. On each cycle, if 'value' is greater than 'ratio' for a given channel, the signal is low. Otherwise, it's high. Simple, in theory!
This algorithm has a few implications. First, with the H-bridge output algorithm, the four output PWM signals (per channel) are phase-coherent. This is necesary for H-bridges to prevent heating or possible H-bridge destruction.
The code runs once per possible output value. Hence the low PWM resolution (four bits). This isn't a problem for most motor control applications, although I'm sure someone will email me and tell me that they need more! More precision means more interrupts, which will limit the maximum I2C frequency.
Since the outputs are updated on a timer, the PWM frequency can be adjusted fairly trivially by adjusting the timer period. The only limitation on this is that the PWM interrupt takes cycles away from the I2C code. I assume that at worst, the I2C code will be interrupted once between each bus sample, which gives a maximum PWM frequency of about 2kHz. If you're running near this limit and in doubt, reduce the I2C speed, or stress-test the I2C bus, or add some error checking to your I2C transmitter. The I2C code won't ACK if it doesn't receive a transfer properly, so there's no (theoretical) risk of getting corrupt data.
H-bridge outputs
If the PWM signal for a given channel is high, we stick the stored 'high' value for that channel on the outputs. If not, we put 'low' on the outputs. That's pretty much it! All of the real work has been done by the I2C code.
There is a slight possibility of H-bridge heating here if the PIC outputs don't switch quickly enough, switch at slightly different times, or if the H-bridge itself can't switch fast enough. This would only come up during a forward/reverse or braking transition. It's not an issue in my application, but a possible improvement would be to have some 'coast' time in the middle of the transition during which the H-bridge stops conducting. This will restrict the maximum output power slightly, but it's not likely to be noticeable given that we are controlling electromechanical devices which can't change direction that quickly anyway.
It's entirely dependent on your situation - the H-bridge you're using, the purpose of the motors you're driving, the drive voltage, and so on. The easiest thing to do, if it's an issue, is to insert the 'coast' period in your control software.