I am looking at using the MIPS M14K port for a product. I notice that the only FreeRTOS port for the M14K does not make use (take advantage of) the shadow registers. On interrupt entry it saves task context straight away before servicing the interrupt. I can see why this is done - it puts everything in a consistent state, ready for any context switch that the ISR may cause. I suppose that if you take the view that any ISR that is doing 'real work' is likely to post a semaphore or send a message, and that a context switch out of ISR is the typical case, then this makes sense. (I did the same in an RTOS I once wrote). However, there may be cases where we have interrupts that we need to service very quickly, even without the need to communicate with a task, and the speed advantage of the shadow registers is highly desirable. Has anyone looked at the possibility of tweaking the port to do this? Or am I on my own on this?
A related side question, which is more architectural: I notice that FreeRTOS does not have a proper scheduler lock (disable pre-emption mode). Rather it relies heavily on disabling/enabling interrupts for critical sections. Has anyone attempted to address this in any of the ports? It should be simple enough to add a soft lock to the scheduler, so you prevent (actually defer) thread switches during critical sections, without affecting interrupt latency? Quite happy to hack this in myself, but if someone has already done it....
Answering my own question on the 2nd point, it looks like vTaskSuspendAll() and xTaskResumeAll() are what I want (provided I don't block in between the two calls!).
The M4K hardware the port was created on didn't implement the shadow registers (from memory) so they were never used. There is no reason not to make use of them, and if you are not using any kernel functionality in the interrupts then you could do that outside of the kernel code. You would probably want to ensure the priority of the interrupts was above configMAXSYSCALLINTERRUPT_PRIORITY though.
You may also be interested in this contribution, although we can't support it directly:
Great! Understood. Thanks for the tips!