[Greg McKaskle]

For 100ms and 20ms loops, I would first profile to see what is taking CPU. I would probably decide to lighten the processing of the 20ms and 100ms loops by removing Smart Dashboard access, refnum by name access, and perhaps some of the scaling and wrappers of WPILib. If using LV, I'd serialize some of the items in the loop to avoid context switches that I really don't need/want. Unless I have tons of these loops, I suspect that would be good enough.

If I'm trying to respond to something in less than 1ms, I'm probably in trouble anyway since the motor controllers only pay attention to their PWM power value every 5 or 10 ms depending on the model. Other actuators seem slow as well, but I don't know the values. The limit switch and other Jag inputs are polled at 1ms by comparison. CAN messages bridged over serial or enet might be fast enough.

Anyway, I'd have to compare the timed loop with very little inside it versus the interrupt.

If I was relatively certain the code wouldn't change, and had the FPGA tools, I'd move the polling into the FPGA. Depending on the complexity of the response, it may be possible to put it in the FPGA too. But again, if the code is going to change, you will shave many times before you complete the project.

Doing the polling in the FPGA, and the response in RT is essentially what FRC interrupts are. If the polling fits the envelope of what is available, it allows high speed monitoring and flexible response for FRC.

Greg McKaskle