![]() |
using interrupts in FRC
I'd like continue a discussion that started in another thread. I made a new thread here as a courtesy to the OP of the original thread who expressed his desire not to discuss the larger issues involved. Here are the things I'd like to have a discussion about. I'd like to hear from FRC programming gurus. Scenario1: 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? Scenario2: 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). |
Re: using interrupts in FRC
The timing of this thread is impeccable. We actually have a situation where we are going to add a sensor, that we think will only be active for 20-24 msecs. I was worried that we need an interrupt to make sure we capture the input condition of the sensor and was asking around so I can advise my software team what to expect. So we have a situation that we want to run some code based on a quick input condition and trigger based on an interrupt is how we would like to trigger a task or loop as well.
|
Re: using interrupts in FRC
If I recall correctly the "best practice" was to use the interrupt to set a flag in the timed routine. That way the interrupt took very few clock cycles and the context switching wasn't too bad. Also it minimized the possibility of getting interrupted during an interrupt.
Obviously this wouldn't work if the sensor had to respond to a condition in an amount of time less than the timer cycle. And from experience, debugging any interrupt routine can be a real pain. |
Re: using interrupts in FRC
Quote:
Why cant you just thread?: If you had a timed task that took as long as in scenario 1, you may want to consider making it into a separate thread (using the Task class in C++ or similar). If any task doesn't require much communication with the main control loop, you could put it in a separate Task. Now, thoughts on Scenario 1: If you offload these timed actions into ISRs, they would take up as much (or more) CPU time as if they were running in the main process. The main disadvantage to this is if it happens inside a time-critical operation (like sending data to the host), it could cause problems. Scenario 2: If the team in question had code that could respond within 1ms, ISRs are a good choice. A hardwired solution would be very difficult to make, debug, and change, compared to an ISR. |
Re: using interrupts in FRC
Quote:
|
Re: using interrupts in FRC
Quote:
Nice suggestion. We will give that a shot on Monday. You might see it work next Saturday...lol....sounds like we are coming to Kokomo on Saturday to the TechnoKats field at 1pm. |
Re: using interrupts in FRC
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 |
Re: using interrupts in FRC
We haven't used the interrupt handling abilities of WPILib (C++) on our team -- is there any guidance around as to what works/doesn't work from inside an ISR? For example, I don't remember seeing any special logic in WPILib to allow concurrent access to the actuator or sensor classes.
|
Re: using interrupts in FRC
Quote:
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:
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 |
Re: using interrupts in FRC
Quote:
In our case, we were using the interrupts to capture an encoder value when a magnet would pass over a zeroing hall effect. In my opinion, this is a perfect use case for using an interrupt where you want a very fast response time. |
Re: using interrupts in FRC
Quote:
|
Re: using interrupts in FRC
Quote:
There is a list of OS functions (not to call) in the VxWorks Programmer's Guide. Basically do not call anything that only makes sense from a task context (no taking semaphores, no delays, no memory allocation, no formatted I/O, no mutexes, doing anything that might block etc) plus no floating point math (unless you save/restore the floating point context). In Austin's example my (wild) guess is that the source of the interrupts (occasionally) did not get turned off. If more interrupts occur than the VxWorks can handle its internal queue will overflow (something like a Windoze BSoD). |
Re: using interrupts in FRC
Quote:
I would probably recommend restructuring the code so that everything can run in a single thread. In an FRC context, my opinion is that typically threads cause more trouble than they're worth. Quote:
I like Alan's suggestion to use a counter, that sounds like a real winner. As a sidenote, when possible, I connect my limit switches to Jaguars. |
Re: using interrupts in FRC
Quote:
|
Re: using interrupts in FRC
Quote:
|
| All times are GMT -5. The time now is 02:38. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi