rtel wrote on Tuesday, May 31, 2011:
So you are saying that the FromISR functions must be modified.
No - the FromISR functions are all capable of working with ports that support nested interrupts already, but they rely on some port layer functions that are not implemented for some ports. For example, they call portSET_INTERRUPT_MASK_FROM_ISR() (which disables interrupts up to a certain level, then returns the old interrupt priority mask) and portCLEAR_INTERRUPT_MASK_FROM_ISR() (which sets the interrupt mask to that returned by the first macro).
All prots could be made to support nested interrupts. How complex this is depends on the architecture. The question is whether the architecture speed and RAM provision warrant doing it.
I suspect the MSP430 could easily support a compromise where the tick interrupt uses the lowest interrupt priority, and any task that wants to use FreeRTOS “FromISR” API functions also use the lowest interrupt priority, then any interrupts that are above that interrupt priority just can’t use FreeRTOS API functions. This is how the PIC24 port works. Other ports have a much more comprehensive multi-priority scheme.
you didn’t comment on my first suggestion.
Can I do something like sending a special message to queue to disable/enable interrupts so that it is not disabled within the ISR.
I don’t understand the question, so can’t answer it either.