portEND_SWITCHING_ISR

Kernel
1

rrrum wrote on Wednesday, March 02, 2016:

Hello,

In many examples I see “portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );” placed as a last line of interrupt routine. This is not always straightforward. In some more complex interrupt handler user may want to put

xSemaphoreGiveFromISR( xSemaphoreMODBUSprocess, &xHigherPriorityTaskWoken );

in some function, maybe after that call some other functions before exiting handler.

So the question is can I put “portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );” after xSemaphore… but not as a last line of handler. Will it work as intended?

Thanks

2

rtel wrote on Wednesday, March 02, 2016:

(or portYIELD_FROM_ISR())

Will it work as intended?

Depends on which port you are using.

3

rrrum wrote on Thursday, March 03, 2016:

I don’t understand your answer, can you elaborate more.

I am using CORTEX M4 port of XMC on GCC.

here is my function

void sys_sem_signal_isr(sys_sem_t *sem)
{
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;

    xSemaphoreGiveFromISR(*sem, &xHigherPriorityTaskWoken );
    portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );
}

which is used as folowing handler

void ETH0_0_IRQHandler(void)
{
  uint32_t status;

  status = XMC_ETH_MAC_GetEventStatus(&eth_mac);

  if (status & XMC_ETH_MAC_EVENT_RECEIVE)
  {
    sys_sem_signal_isr(&eth_rx_semaphore);
  }

  XMC_ETH_MAC_ClearEventStatus(&eth_mac, status);
}
4

rtel wrote on Thursday, March 03, 2016:

I don’t understand your answer, can you elaborate more.

I said “Depends on which port you are using.” because, the answer to your question depends on which port you are using, and as you didn’t say, I couldn’t answer the question.

If you are using a Cortex-M4 port then you can call portEND_SWITCHING_ISR or portYIELD_FROM_ISR at any time - it does not have to be at the end of the ISR.

5

richard_damon wrote on Friday, March 04, 2016:

If I remember right, on the M4 the portYIELD_FROM_ISR triggers a lowest priority interrupt to cause the task switch, which will be blocked by the current ISR running, so exactly when that interrupt is triggered doesn’t matter.

On the other hand, in the PIC24 port, the portYIELD_FROM_ISR actually does the task switch, and continues execution at that task, and the code that follows isn’t executed until the original task gets switched back to, so it really does need to be the very last code in the ISR.

If you wanted to write you ISR so it can work on system like the latter, then any function that the ISR calls which might set the HigherPriorityTaskWasWoken flag, needs to be passed the flag so it can pass that to the API, and the ISR tests it as its last step.