PIC24 / dsPIC port and DSP addressing modes

ericwalker wrote on Monday, February 22, 2010:

I have experimented with FreeRTOS in the past on a dsPIC33 but at the time was not using any DSP libraries.  I am begining a new project that will require using several of the DSP library routines and was about to build it on top of FreeRTOS to make handling the multiple tasks easier when I came across the following post on the Microchip forums.

http://www.microchip.com/forums/tm.aspx?m=478816

The issue stems from the special addressing modes used by certain DSP routines.  These require the use of the MODCON register which FreeRTOS appears not to push/pop when needed.

Has anyone here had any experience with this issue?

-Eric

richard_damon wrote on Tuesday, February 23, 2010:

It shouldn’t be too hard to add the saving of that and the related registers (I suspect that you would need to save MODSRT/END registers too. You just need to add the Push/Pop to vPortYield in portasm_dspPic.s, and the matching pop to the portRESTORE_CONTEXT macro in port.c, and add initial values for the registers in the stack frame defined in xInitialStack in port.c

That should be all the places that know about the stack frame used for task switching (you may need to raise the minimum stack size a bit to compinsate for the additional information on the stack).

ericwalker wrote on Tuesday, February 23, 2010:

Richard,

Thanks for the quick reply.  It has been several months since I played with FreeRTOS and I have not yet used the DSP functionality of the dsPIC so I am a bit hesitant to jump right in and make changes to the kernel code.  But, if nobody else has worked around this issue and can say exactly what they changed - and that they tested it and it worked - then I may have to tackle this myself. 

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.

Can anyone confirm or deny that the changes mentioned are the only ones I would need to make?

Thanks again.

-Eric

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?

Regards.

ericwalker wrote on Tuesday, February 23, 2010:

Richard,
I appreciate your involvement in this issue. 
In my application I will probably be doing some convolution and/or filtering of data coming from the ADC at one rate and then running a PID loop at a lower rate.  I am very early in the design of this project – which is for graduate work, not my day job – so I am speculating a bit on what I will need to do.
If I am limited to running all the DSP routines from one task that is probably not a significant problem.  However, I anticipate I will have DSP processing running at very different rates, the input filtering, CIC, etc. the I & Q processing, the PID loop, etc.  At this stage I would think it might be easier to separate these in to more than one task if possible.
Unfortunately I am not up to speed enough right now to add much original input to this discussion.  I just started reading through the Programmer’s Reference Manual last night to try to better understand the special addressing modes of the DSP class instructions and how those might be affected by context switches or even interrupts.  I will also have to study the FreeRTOS code to understand what it is doing on context switches.
There was some continued discussion on the Microchip forum, and one comment specifically, that I may still need to save and restore the MODCON register but, that it may not be possible to have DSP class routines running in more than one thread because some of the status bits are read-only and so cannot be restored by a context switch.  Unfortunately, as I said before, I am not familiar enough with the inner working yet to confirm or deny this assertion. 
Thanks again for your time on this issue.

-Eric

jjones2 wrote on Sunday, March 04, 2012:

Eric,

Did you have any luck using the DSP with different FreeRTOS tasks? I too would like to use the DSP with tasks running at different rates.