Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

PIC24 / dsPIC port and DSP addressing modes

Posted by Eric W on 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

RE: PIC24 / dsPIC port and DSP addressing modes

Posted by Richard Damon on 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).

RE: PIC24 / dsPIC port and DSP addressing modes

Posted by Eric W on 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

RE: PIC24 / dsPIC port and DSP addressing modes

Posted by Richard on 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.

RE: PIC24 / dsPIC port and DSP addressing modes

Posted by Eric W on 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

RE: PIC24 / dsPIC port and DSP addressing modes

Posted by jjones on March 4, 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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists