If you omit portYIELD_FROM_ISR( xHigherPriorityTaskWoken ) from the interrupt handler how does the operating system behave compared to using portYield?
I am guessing if portYield is not used the system returns to the task it was executing when the interrupt occurred rather than the task using the interrupt.
In some cases could this be a good thing to do if the task waiting for the interrupt is low priority and no more interrupts on that line will occur? There are some high priority tasks that I don’t want to switch out of if an interrupt occurs that is serviced by a low priority task.
portYIELD_FROM_ISR might immediately invoke the scheduler activating the next ready task i.e. the task with the highest prio ready to run. It’s not necessarily the task consuming the event you signaled in the ISR.
Omitting it just delays the scheduler invocation until the next systick (which might be up to a complete tick period).
Do not worry about higher-priority tasks: it is not possible to have a lower-priority task running, unless all higher-priority tasks are in a blocked state".
Tasks with the same priority will share the CPU time, normally swapping at each systick.
