rtel wrote on Thursday, March 10, 2005:
I will have to take another look at this but I think that interrupts can already be enabled prior to the kernel being started - provided your application does not try to use the kernel features.
It may be that the demo applications do not enable interrupts, but the kernel itself only disables them within the StartScheduler() function. They also get enabled/disabled during critical regions, but this would not prevent your serial port ISR operating.
To elaborate a bit using your example of the serial port. Serial drivers can be written to not use any kernel features and can therefore be used at any time. However, if your serial port driver uses, for example, cQueueSendFromISR() then the queue you are sending to must or coarse be created first. Also if the send causes a task switch there will be problems but this would only be the case if a task was blocked on the queue and if the kernel was not started how could this be?
One good change at the kernel level would be to initialse the scheduler locking variable to a non zero value - and only set it to zero during the StartScheduler() function - after interrupts have been disabled. This would make it impossible for a context switch to be even attempted prior to the kernel being started. However care would still be required and the actual behaviour would depend on the port.
Just thought of one other thing - pxCurrentTCB would also have to be initialised … this might be a bit tricky. Best not do anything that tries to use the kernel until it has been started.
I will ponder this one some more …