int for avr32 using xHigherPriorityTaskWoken

ivansb wrote on Thursday, October 21, 2010:

I’m following the example in the “Using FreeRTOS Real Time Kernel”  (version 1.3.2).
I couldn’t find any use of portSWITCH_CONTEXT() and portYIELD_FROM_ISR() in the port distributed with Atmel software framework neither they are used in any example contained in FreeRTOS  6.1.0.

How am I supposed to write an interrupt routine that actually return to the higher priority task?

thanks

davedoors wrote on Friday, October 22, 2010:

I think the text states that different ports do this in different ways. Each port documentation page has a section called ‘interrupt service routines’ which explains how to do it for that port. The AVR32 page is here http://www.freertos.org/portAVR32.html

ivansb wrote on Friday, October 22, 2010:

Thanks.

I’ve already read that page but apparently I’m missing the meaning or its not giving an example of what I was looking for.
From what I’ve understood from the book if I’m

xSemaphoreGiveFromISR(xBinarySemaphore, &xHigherPriorityTaskWoken);

I could then conditionally return to the higher priority task calling

if( xHigherPriorityTaskWoken == pdTRUE) {
  portSWITCH_CONTEXT();
}

Skipping a redundant return to the OS.

I’m not really sure if this correspond in functionality to the example you pointed at.
Furthermore I’ve a couple of doubt:
It is said that “calls made to API functions from within an ISR must be contained within a critical section refers to just interrupt with same priority of the OS”
But then I’ve not completely clear:
configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY at:
http://www.freertos.org/index.html?http://www.freertos.org/a00110.html

So summing up I have:
1) interrupt with higher priority than the OS that:
  a) can’t make context switch and use the “xHigherPriorityTaskWoken” functionality
  b) can’t make calls to the OS API
2) interrupt that have same priority than the OS
  a) and don’t use API
  b) and use the API but don’t require context switch
  c) and use the API and require a context switch
3) interrupts that have a lower priority than the OS
   a) b) c)…

1) can’t make a context switch I could write them without prologue/epilogue (portENTER_SWITCHING_ISR/portEXIT_SWITCHING_ISR) and set the attribute to interrupt inspite of naked

2c) and 3c) seems requires prologue and epilogue and can be declared naked.

What about 2ab) and 3ab)?

What does it happen if I skip the prologue/epilogue in 2) and 3)?
Interpreting from the example in the book that would give control back to the OS that in turn will give control to the higher priority task… requiring one more context switch rather than just returning to the higher priority task directly.
Is it?
Would it be reasonable if I expect the interrupt to rarely interrupt higher priority tasks to skip the prologue/epilogue?

Did I get it right? Partially right? Wrong?