rtel wrote on Tuesday, February 23, 2010:
The dsPIC port was created some time back, but I seem to recall discussing this with Microchip at the time and the feeling was that the true deep DSP context didn’t need to be part of the task context because it was very unlikely that an application would make use of it from more than one task in any case. If only one task is using the registers then they don’t need saving or restoring - unless you can tell me otherwise(?).
In this sense I suppose the DSP registers are being treated sort of like a peripheral, although code is generated automatically that uses the registers by the compiler so its a bit of a weak analogy.
richard_damon is right in that it should be a trivial task to add the DSP registers if it is thought necessary - that is if you are going to be performing DSP routines from more than one task. All that should be required is extra space to be reserved on the stack where the stack is initially set up - then the DSP registers to be pushed and popped along with the other registers in the portSAVE_CONTEXT() and portRESTORE_CONTEXT() macros.
Someone on the Microchip forum mentioned that another RTOS had a DSP flag that would tell the kernel whether or not to save the DSP related registers. This seem like best general solution, adding a setting to the FreeRTOSConfig.h file.
Yes this would be a good solution too and this is in effect how we deal with processors that have floating point hardware. Rather than have the overhead of saving and restoring floating point registers for every task, even if the tasks aren’t using floating point (as most don’t), the task-switched-in and task-switched-out macros are configured to save and restore the floating point registers for just the tasks that have indicated that they need them. It makes a very efficient (in both memory and execution time) solution, but is perhaps just a little ugly?
I would be interested to know how people are using the DSP libraries in real life applications. In my experience (which is limited to my experience) they would tend to be used for things like field orientated motor control, which is performed very quickly and repeatedly, and therefore I would image the original assumption that this would not be done from more than one task would hold. Maybe that is too restrictive?