Quote:
Originally Posted by Ether
A team has code which uses 100ms and 20ms periodic tasks, and they are running low on throughput margin (i.e. CPU usage is too high). They think that they can reduce CPU usage by using interrupts instead of periodic tasks. What say you?
|
The period of the tasks is well within the bandwidth of the OS and hardware we use in FRC. The real question is the run time in each period. If we have 3 tasks that run t1, t2, t3 periods and require c1, c2, c3 computation time in each period then you calculate c1/t1+c2/t2+c3/t3 and have some feeling for how much bandwidth is being used. Of course there are other things going on. The OS consumes bandwidth for its clock and scheduler. In FRC robots some bandwidth is used by the task receiving DS messages plus one might have PID callbacks etc. If the sum of all terms for the OS, app and WPI tasks gets anywhere near 1 then you are in trouble (actually lower than 1, see
http://en.wikipedia.org/wiki/Rate-monotonic_scheduling).
If the events that generate the interrupts are periodic and you are running the same-ish code to handle the event then you are not saving much time. However if the events are aperiodic using interrupts may save considerable bandwidth. If they use interrupts, the best practice is to quickly 1) determine if your hardware caused the interrupt 2) clear/reset the interrupt cause 3) set a flag, give a semaphore etc to synchronize with code running in a task to react to the event.
Quote:
Originally Posted by Ether
A team has subsystems that need to respond to sensor data changes within 1ms. Should they: a) use Interrupt Service Routines to control these subsystems, or b) carefully investigate other approaches (such as a hardware limit switch directly connect to a motor controller for example).
|
1ms interrupts can be handled by the hardware and OS we use in FRC. The interrupt latency of our system is measured in single microseconds. Again the real question is how long does it take to "handle" the interrupt. If the interrupt is periodic or the worst case is nearly periodic you can analyze the effect on the system just as you would a task.
BTW, handling a mechanical limit switch using interrupts is a little tricky if the hardware does not debounce the input. I don't know that our DIO inputs do this.
HTH