Dilemma perhaps someone can help me to solve …
In thinking ahead, I’m trying to use FreeRTOS efficiently with a high rate ISR running:
I have a ISR that is triggering every 80 microseconds on a Pic32MX processor and which I expect to run continuously.
Solution #1:
One solution is to use deferred interrupt processing:
- From the ISR that triggers every 80 microseconds, call xSemaphoreGiveFromISR()
- From a task siting on a xSemaphoreTake(), then task will wake up, and handle the processing.
My concern is in regards to other tasks: With this solution (using a semaphore give from an ISR) the FreeRTOS kernel and other tasks are guaranteed to context switch from what they are tasked to do and yield to this higher priority task to do deferred work at a 80 microsecond rate.
Deferred interrupt processing is not bad per say, but I’m concerned about it at such a high rate and the affect it will have on the other tasks. Deferring the work to a FreeRTOS task, I would say there is a lot of context switching that will the be continuously occurring.
If someone said, “Oh no, FreeRTOS semaphore’s inure a 200 microsecond penalty between xSemaphoreGiveFromISR() and xSemaphoreTake()” then it’s clear that this wouldn’t work. Of course of course, timing depends on processor port and type.
** Solution #2: **
Alternatively, do all the processing in the interrupt itself. When enough processing is performed, then notify a task the work is done.
- One problem with that, is that I’m then spending a lot of time in the ISR doing processing. Because of this, I may miss other interrupts.
- With deferred interrupt processing and Using a task, I can prioritize how things run!
Feedback …
Any input, thoughts, or ideas on which direction to go would be great? Others may have a better understanding of the performance impact that can occur between both solutions.