I’ve just started using FreeRTOS with an ARM Cortex m4 device and I’m not sure how to handle an interrupt situation.
I’m using a sensor that provides an interrupt pulse when data is ready. Let’s say this pulse is 100uS high.
When the interrupt is received, I need to read the data with I2C or SPI.
I can live with some jitter, as long as the interrupt is not missed.
I have configMAX_SYSCALL_INTERRUPT_PRIORITY = 5.
My understanding is that if I set my GPIO rising edge external interrupt priority to 5 or above (lower priority), the RTOS functions could cause my interrupt pulse to be missed.
So, I set my external interrupt priority to 1.
Ideally, I would like the interrupt to unblock a task which will then read and process the sensor data, but I can’t call any RTOS API’s with a higher priority (lower number than 5).
So, what’s the proper way to handle this situation?
Typical interrupts on Arm get set by an edge of the interrupt line, so even if the line goes back low, the interrupt will still occur (and the processor tends to need to write to a register to clear the interrupt request), so it won’t be missed (but double check with your implementation, as there are several different interrupt controllers used with the ARM Cortex series of processors) Also most devices assert their data-ready interrupt until data is read, not just a narrow pulse.
Also, FreeRTOS itself will possibly block the interrupt for just sort periods of time. One of the major design critera is minimizing the worse case period that interrupts are blocks, so 100us is likely much longer than FreeRTOS itself will block interrupts, thus even if you do need to catch the interrupt in that time period, you are probably still ok (unless you have a VERY slow processor). Unless your applicaton creates a too long critical section, you should be ok.
I would say for what you describe, I would just set the interrupt priority within configMAX_SYSCALL_INTERRRUPT_PRIORITY and use a FreeRTOS call from the ISR.
I have at times needed an interrupt that needed low enough jitter that I did want it above configMAX_SYSCALL_INTERRUPT_PRIORITY, so it couldn’t make any FreeRTOS calls. If that ISR did want to signal somthing through FreeRTOS, I would find some other interrupt vector to use, and configure that lower in priority so it could make the FreeRTOS calls, and have the high priority interrupt manually trigger that interrupt so when the ISR exits that interrupt get called, and it then can make the call.
The more obvious answer is you are on a Coretex M4 put the sensor on the FIQ then it isn’t anywhere near the IRQ system FreeRTOS is using and enabling and disabling the IRQ’s on.
The FIQ has a higher priority that than the IRQ it doesn’t matter what
priority FreeRTOS is running it can not stop the FIQ.
You then act like a multicore system you simply do the minimum required
for the FIQ interrupt and clear it. Next you post off a message to
FreeRTOS to handle what doesn’t need to be handled immediately by the
FIQ. You can even get super tricky and if the FIQ notices stuff is
building up it can boost the FreeRTOS processing priority for it’s
process thread.
On 10/04/2019 10:17 pm, Richard Damon wrote:
But using FIQ put him in the same situation as a too high priority
interrupt, that he can’t call the FreeRTOS Interrupt API.
Sorry for duplicate I think I answered you privately Richard.
However for clarity the FIQ has a higher priority than IRQ that FreeRTOS is running and it will interrupt FreeRTOS regardless of whatever it is doing and even if it has the interrupts off. You process what you need to do, clear the FIQ and post a message or stick stuff in a queue and signal FreeRTOS to do whatever it wants with whatever you did. FreeRTOS never needs to know that the data is coming from an FIQ interrupt and nothing needs to go near the FreeRTOS interrupt system.
Leon, I think you may be mixing threads. srcad has a interrupt he doesn’t want to miss, and that interrupt wants to signal a FreeRTOS task.
The simplest answer is make it high priority but within configMAX_SYSCALL_INTERRUPT_PRIORITY so it can make the FreeRTOS calls.
If that might miss the interrupt, then the next step is put it outside configMAX_SYSCALL_INTERRUPT_PRIORITY (possibly FIQ), so FreeRTOS can’t make the interrupt miss, but then software trigger an interrupt within configMAX_SYSCALL_INTERRUPT_PRIORITY, and then that interrupt can call FreeRTOS. That first ISR must NOT make any FreeRTOS calls or you may corrupt the system state, so it can’t ‘Post a message’ or ‘stick stuff in a queue’, or at least not in the FreeRTOS sense.
Your references to ‘multi-core’ seem a bit off, as we have no indication that we have a multi core.
Now the typical multi-core situation uses a method similar to what I am describing, the other core triggers an interrupt within configMAX_SYSCALL_INTERRRUPT_PRIORITY on the processor it wants to signal (and multicore systems often have such an interrupt just for this purpose),
Just remember that generally, the FIQ is effectively a very high priority IRQ, one with a priority above the limit, so its handlers can’t use the FreeRTOS API.
Depending on the Vectored Interrupt Controller your chip has, the FIQ may be somewhat faster response, which was why they were created. In the ‘Classical’ IRQ system, all IRQs went to a common handler, that talked to the VIC, and then vectored to the appropriate handler. This of course adds some overhead to the interrupt process. The FIQ had the advantage that it was geneally a non-multiplexed vector. Later processos, like the Cortex M series, have a more advanced VIC that bypasses the need for that initial code sequence, so all interrupts go directly to the appropriate handler. The FIQ also uses a slightly different interrupt sequence which can be faster to enter/exit