anonymous wrote on Friday, January 12, 2007:
I have a common ISR that handles all (VIC default vector) IRQs, including the tick interrrupt.
extern void __attribute__ ((naked)) PortIRQDispatch(void);
ISRDispatch() does a table lookup to properly dispatch to the correct ISR. NeedTaskSwitch() is implemented in tasks.c as:
__static portTickType lastCount;
__short didTick = lastCount!=xTickCount;
__lastCount = xTickCount;
__return didTick || uxTopReadyPriority>pxCurrentTCB->uxPriority;
The above version works as I had hoped. The ‘didTick’ trick ensures that true is returned whenever vTaskIncrementTick() is called in the ISR. The following version does not work as expected.
The test has a lower priority task in an infinite loop. A higher priority task delays for a certain period. It never appears to run after the delay period. But then I have some difficulty with debugging. I see NeedTaskSwitch() return true at the appropriate time, but I can’t seem to properly step out of the restoring of the context to see what is happening. I don’t know if the stepping out issue is an artifact of the actual
problem, or if it is just an artifact of my debugging tools. Visually, during the final
__SUBS PC, LR, #4
the LR has the same value as the PC, so it just steps back 1 instruction and appears to be looping infinitely. But this is inconsistent with the free-running behaviour so I tend to suspect the debug tools rather than think this is the actual problem. Free-running, a breakpoint after the delay in the higher priority task never triggers, and the lower priority task continues looping.
The truth be told, I never examined the registers of the restored context to try to figure out which of the 2 tasks was being restored. I may take some time to do this some time in the future. Or, if you are willing to look at it…