myserious wrote on Tuesday, March 15, 2011:
Richard & Crew
Could you clarify the sequence of operations for ISRs to use the system stack when the ISR uses the Queue FromISR functions that need that trailing “if (hiPriTaskWaiting)” check?
Until we get our hands on the OpenRTOS USB Device stack, we’re using the Microchip device stack, which is a pretty big ISR - especially as it hooks down into our code which drops the incoming char (or buffer) on a queue in the interrupt context. So we’re motivated to switch stacks when it is running to avoid having to have that much room on 10+ other tasks.
It seems that the first step is to “wrap” the ISR from an assembly file like this:
vUSBInterruptHandler:
portSAVE_CONTEXT
jal USBDeviceTasks
nop
portRESTORE_CONTEXT
.end vUSBInterruptHandler
of course with the interrupt mapped in the .C file like this:
#pragma interrupt vUSBInterruptHandler ipl3 vector 45
In the actual C that is called (in this case, the Microchip USB device ISR-not-as-an-ISR function
USBDeviceTasks
), there is no special coding until we do the enqueue… where we record if a high priority task is waiting.
Here’s where it gets interesting. At the end of that C function, we of course add:
portEND_SWITCHING_ISR( xSwitchRequired );
Now, is that really correct? we’re calling the yield but we have’t “unwrapped” in the assembly wrapper the portRESTORE_CONTEXT, so we’re yielding whilst the stack is switched to the system stack.
Are there any issues there? We seem to be getting some odd behaviour when we take this approach and we’re trying to ensure we understand the proper flow so as not to chase ghosts.
Thanks
The Serious Team