[BradAMiller]

Wow, tough crowd!

Alan - if I suggested that interrupts were evil, that wasn't my point and I'm sorry for not making that clear. And I certainly didn't mean to suggest that lots of bugs are a necessary part of interrupt logic. My point was that having dedicated hardware is a good thing and makes programming easier and offloads the CPU running the robot program. But let me try to answer some of your questions directly.

You mentioned that you never received a satisfactory answer on the questions of "speedometers" and PID time-based code.

By speedometers, I'm guessing you were asking about measuring the period of signals from encoders on rotating shafts for measuring motor speed directly, please correct me if that's not what you meant. There will be 8 hardware quadrature encoder inputs and 8 hardware counter inputs. Each of these can track the period as well as the count. The period gives an instantaneous representation of speed. Any digital I/O port can be routed to any of these encoders/counters.

There are many ways of solving your issue with time-based algorithms like PID integration. One is to use the Notification class that will periodically call some function in your program. You can, for example, request notification every 20ms and do the PID calculations there. Even though it is not a true hardware level interrupt routine, the function can get the precise time and easily apply the appropriate weight as it's integrating the error value. There are many additional mechanisms that could be used for solving the same problem.

You asked what i meant by "dedicated hardware" and asserted that it wasn't really necessary and ultimately could just be replaced by faster CPUs.

I believe that having hardware to supplement the CPU is a good thing. Like video cards in PCs - it doesn't matter how fast CPUs get, they'll never be as fast as dedicated pipelined graphics engines we see on modern video cards.

Same is true on the robot. A few years back there was a gear tooth sensor that generated a (about) 40 microsecond pulse for one direction and a (about) 70 microsecond pulse for the other. If the interrupt on the gear tooth sensor occurred while a higher priority master processor interrupt was being handled (delaying the start of the gear tooth sensor interrupt handler) there would be no way of measuring the pulse width. And we couldn't determine the direction. That's an example of where using the CPU just doesn't work. With "dedicated hardware" we can easily know and the program doesn't have to deal with those complexities.

You mentioned Kevin Watson's code with respect to encoders and A/D converters. Kevin was able to accomplish amazing things with PIC chips. He really knew that hardware better than most people I've met and all FIRST teams recognized that.

In his encoder FAQ he talks about about phasing errors caused by limited software sampling and interrupt rates that give false interpretations of encoder direction sensing. This is not a problem when there is dedicated hardware looking at each encoder channel, it's only an issue when the CPU is over taxed with many devices competing for the CPUs resources or encoder rates are too high.

D/A converters can be sampled with software in interrupt routines, and as you pointed out Kevin's interrupt-based example proved that. But we now can achieve about 500k samples/second aggregate rate on each of two modules without the CPU getting involved at all. And that's with hardware oversampling and averaging and integration for gyros. I'm not saying this can't be done without dedicated hardware, but having it sure seems better to me than not having it.

We hope to continue to get input from the FIRST community, make improvements and address concerns as they come up. Please keep asking questions, but please don't shoot the messenger. I for one would prefer to see constructive questions targeted at the hardware/software and not the developers.