I agree that DIO1_ISR is called in an ISR context. So it's right for it to call xQueueSendFromISR rather than xQueueSend, for example.Hmm. My understanding is that if the ISR calls a function (here gpio_default_irq_handler calls DIO1_ISR as you pointed out) the called function is still being run in the ISR context (same stack or register bank etc.). So I think the callback is still a sort of ISR.
I'm more concerned about the call to portYIELD_FROM_ISR, which usually happens once before an ISR returns. Here's an example. Suppose interrupts are disabled for a while and, during that time, multiple GPIO events occur. When interrupts are enabled again, the ISR for GPIO interrupts is called, which invokes multiple callbacks, each of which potentially calls portYIELD_FROM_ISR and potentially even with different parameter value.
I think it might be alright because portYIELD_FROM_ISR might go something along the lines of...
Code:
void portYIELD_FROM_ISR(bool wake_task) { if (wake_task) g_should_yield_after_isrs = true;}Edit:
The answer is, it depends on the platform. On some platforms portYIELD_FROM_ISR calls the supervisor directly so should be called at the end of the ISR. On platforms, like ARM Contex M0+, instead portYIELD_FROM_ISR pends a deferred exception which will be called after all ISRs exit, which in turn calls the scheduler. Here's the Code from the Cortex M0+ port:
Code:
#define portEND_SWITCHING_ISR( xSwitchRequired ) \ do { if( xSwitchRequired ) portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT; } \ while( 0 )#define portYIELD_FROM_ISR( x ) portEND_SWITCHING_ISR( x )Statistics: Posted by alastairpatrick — Mon Mar 25, 2024 10:02 pm