[Kevin Sevcik]

Our team actually ran into one of the die issues with Timer1/3. Specifically, the external clock input is exposed on one of the I/O ports, so we were using Timer1 as an async counter to count encoder pulses. This would have worked brilliantly, as it required no interrupts, and could handle a very high pulse frequency. Unfortunately, the die issue with 16-bit R/W of the timer in async mode was a large stumbling block and limited our resolution once we figured it out. Otherwise, it worked brilliantly for measuring the shooter wheel. Since that only ever goes one direction and all that.

Anyways, I'm questioning the need of an entire co-processor for simply processing the shooter encoders and PID. Or atleast the PID. Unless you're being fancy, your PWM update rate on the controller is rather limited, so I can't see the the advantage of doing a really fast off-board calculation and then queuing it up to wait to be output in the RC.

To Qbranch,

I recall having some difficulties with using shifts instead of divides to try to save processor cycles. Specifically:
A. I don't know if it actually saves any time or not.
B. I'm pretty sure shifting a signed 16-bit number didn't preserve the sign, which made it useless for trying to save cycles, since all the negative numbers ended up positive.