I am supporting a code base that uses xSemaphoreGiveFromISR (in both FreeRTOS 4.1 and 7.6), but does not try to force a context after a task might have been awoken (i.e. neither the return value of xSemaphoreGiveFromISR (4.1) nor the 2nd argument (7.6) are checked to decide whether a call to portYIELD_FROM_ISR() is required).
This code has been running for some time, being called from the tick hook and “seems to work”.
What is the downfall of not calling portYIELD_FROM_ISR once the semaphore is given from the ISR? Does the task eventually get awoken by some other mechanism, and this issue becomes transparent to the user?
Or is it that this specific xSemaphoreGiveFromISR call never requires forcing a context switch? This semaphore is waking up the task with the highest priority in the system.
A second question, related to the difference in API between 4.1 and 7.6 for xSemaphoreGiveFromISR. In 4.1 the second argument is passed by value, while on 7.6 it is passed by reference. The xSemaphoreGiveFromISR example for 7.6 shows to use the argument as means to decide whether or not a context switch is required, while on 4.1 the return value of the function used to be used.
Looking at the code for 7.6 and comparing with 4.1, it seems the return function of xSemaphoreGiveFromISR in 7.6 could also be used to decide whether a context switch is required. Is this a fair assumption?
Last, in 4.1 can portYIELD() be called from an ISR context? More precisely for the AT91SAM7S port:
#define portYIELD() asm volatile ( “SWI” );
For this port there doesn’t seem to be a version available to be called from the ISRs.