Yielding from ISR on preemptive vs cooperative

ecab wrote on Friday, February 24, 2017:


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.


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?


EDIT: Image Links

rtel wrote on Friday, February 24, 2017:

I’m not sure if you are reporting a problem, or that the behaviour is
just not what is necessary in your particular application.

I don’t think we would add something like the macros you have created as
I’ve not come across this scenario before - when switching between
co-operative and pre-emptive would be done more than once. Starting
co-operative, and then changing to pre-emptive later, or the other way
around, are normal, but switching back and forth is not. Also, as you
have shown if users want to do that then it is easy enough for them to
put in the pre-processor guards themselves.