I marked the direct answers with ***s. My advice is at the bottom.
What is the sampling rate of the analog inputs?
*** The number is dependent on the I/O module. It is printed on the case of each module, but may need some explanation. I believe you will find that it is 500kS/s aggregate. It can run slower, can throw away values, and WPILib implements a scan list which can read interleaved channels and doesn’t have to read them sequentially. This allows some channels to effectively read higher rates and others lower.
How many interrupts can we have per analog/digital input?
*** Eight total, any mix.
Are the interrupts triggered off the fpga or the processor?
*** The fpga raises the interrupt on the cpu. The cpu executes a low level handler, and for LV, it runs a form of deferred procedure.
What is the delay between the time an input changes and the interrupt is exerted?
*** I don’t have numbers for the latency between I/O and the scheduling of your code, but it should be quite small.
How many interrupts can we have total?
*** Eight.
Are there any other limitations concerning interrupts?
*** The limits are the I/O conditions that are programmed into the fpga. With the fpga tools, you could have alternate conditions and you could synthesize more.
The goal of this would be to eliminate polling inputs in the code.
*** Advice
As Ether pointed out, the code to grab a raw analog voltage is quick. The scaling calculations add a bit of overhead, but for most FRC mechanisms it is reasonable to use the simple polling loop to monitor and control your device. The interrupts are available and fair game, but they are a bit more advanced and you shouldn’t overuse them.
For any given device that you are trying to control or respond to, I’d first calculate how quickly you need to respond. Use the distance and rate of travel, or whatever your phenomena is to calculate your response time. Can you afford to check once a second, ten times, one hundred times, or do you need to read even faster. As this number gets higher, the overhead of doing it in the CPU gets in the way, but this is dependent on how efficient you are at doing it. The interrupt mechanism essentially moves the poll into the fpga. It adds it to the latching code that moves the value from the bus into the buffer or register, accumulates, calculates a level trigger, etc. This is still polled, but it is now in someone else’s loop.
I didn’t find an FRC example for interrupts, and the one in Find Examples assumes you have the FPGA tools in order to compile for different cRIOs. So be sure to start with something simple and make sure that your assumptions are correct.
Greg McKaskle
