ecab wrote on Friday, February 24, 2017:
Hello,
I have been using FreeRTOS on cooperative mode on an Atmel SAMA5D3 Xplained for a while and wanted to check how my system behaved with a preemptive scheme when I came up with this problem and wanted to share the way I circumvented it so maybe you can think about adding this to future versions.
First I realized that in order for preemptive to work as I wanted it to work I had to end every interruption with a portYIELD_FROM_ISR( xHigherPriorityTaskWoken)
. Otherwise I had some problems when an interrupt happened when in IDLE (it would not switch to the higher priority task and stay in IDLE for the rest of the tick).
So I added this to every interruption and everything worked fine. Then I switched back to cooperative changing the value of configUSE_PREEMPTION
(not removing the portYIELD_FROM_ISR
call) and got this behaviour:
In this screenshot I have the green task running with low priority. The orange task is a deferred interrupt handler and the ISR just sends a notification to this task so it wakes up. The problem for me is since it is in cooperative I would like it to return from the ISR to the green task (I’d have to remove the portYIELD_FROM_ISR
) so if I want to smoothly switch between the two desired behaviours (preemptive and cooperative) I would have to add something like this to the end of every interrupt:
if (configUSE_PREEMPTION == 1)
{
portEND_SWITCHING_ISR( xHigherPriorityTaskWoken);
}
Since this is a hassle I created the macros that can be seen in the following screenshots to add to the end of the interrupts so I can just change the value of configUSE_PREEMPTION
to switch between the desired behaviours.
http://imgur.com/ZfzYWSJ
http://imgur.com/aPOt382
1- Is there already a way to do this and I haven’t seen it? And if there isn’t, would you consider adding something like this to future versions?
2- Am I the only one expecting this behaviour?
3- Do you see any side effects for this?
Regards!!
EDIT: Image Links