The future

Stuff I'd like to do for Version 2:

• Raise the I2C frequency. It's not that I need a higher I2C frequency - it's just embarassing seeing every other device doing a standard 400kHz, and mine piddling along at 8kHz :-)
• Dynamic control over the PWM frequency. This implies a whole new command format as well, but I expected that for any updates.
• Support I2C reads. This isn't necessary at the moment - but it's generally a nice thing to do. It'd also be nice to support less common I2C commands such as slow starts and long addresses.
• Add more channels. More motors is more better!
• Switching time compensation. This is intended for larger MOSFET-based H-bridges which might not switch on and off quickly. In the transition period, they heat up and waste power. With the right hardware, you can switch off the lower pair of MOSFETs before the upper pair are turned on, reducing heat and power wastage.
• Temperature monitoring. Because I'm paranoid.

  Some of these things can be done on the same PIC device, but the a better solution would be to change technologies. The AVRs often have onboard I2C, so that would get me part of the way (and remove a pretty major testing burden, as well as possible licensing issues). Probably a better solution would be to use a CPLD or FPGA. Current devices have clock speeds vastly in excess of what's necessary in this application, so there's no performance problem. They tend to have a lot of I/O, so many channels (at least four) would fit on a single device. And the programming languages (VHDL or Verilog) tend to be much more suitable for this type of work, where you're mostly twiddling bits in registers and maintaining a state machine. (I later wrote the VHDL for everything except the I2C interface in about half an hour.)

  The only problem I can see so far is that the current devices have relatively low maximum I/O voltages - typically 3.3V. (The internal cores run at significantly less than that; 2.5V is a typical maximum nowadays). So there'd need to be some support circuitry to provide output buffering. Remember that a crisis can also be an opportunity (crisitunity! or not); this would give the possibility of arbitrary output voltages for your difficult-to-drive H-bridges.

  Most current FPGAs are SRAM-based, so they lose their program when power is lost. There are plenty of ways to get around that - use an OTP or Flash-based FPGA, or a slave Flash chip to program the FPGA on startup - so that's not a big deal.

  FPGAs are awesome.