Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


dsPIC33E port

Posted by dragonflight1 on February 6, 2015


I know your position on this (it is even in the code), but I thought I would point out a couple of points that may influence you.

Firstly, it would appear that no-one with the exception of swissembeded has used the DSP features of any PIC! and he seems to have come and gone.

Secondly, while on the surface it appears that the dsPIC24/30's allow the saving/restoring of the DO registers, in reality there is a limit of 7 levels (read-only 3-bit nest register) and in practice they are limited to 2 levels (hardware stack) as Microchip's dsp library makes no accomodation for a software stack. Worse the DSP accumulator status flags (overflow and saturate) are read only and not restorable (except for testing and executing code to set the flags). To be fair I could not find any code in the libraries which used those flags. All of which to say that, practically, on the dsPIC24/30's one is restricted to 1 process and on the dsPIC33E's 2 processes using the DSP engine.

Of course you are asking yourself, if no-one is using the dsp then why bother? Given the PIC's many, many varieties it can be a peripheral choice. In particular the dsPIC33EPxxxGP/MC50X has a CAN peripheral while the PIC24EPxxx's do not. The EP series is interesting because it has the largest flash size available (512Mb) as well as a decent amount of RAM (48Kb)

Finally, as you may remember there is a port on the FreeRTOS interactive site for the dsPIC33Es which I don't mind maintaining (albeit slowly and not during the summer - can't waste the short sailing season)


dsPIC33E port

Posted by rtel on February 6, 2015

Other than the

statement in the port file, which could be commented out, I don't think there is anything particularly stopping the use of FreeRTOS on the E parts provided the user understands that certain hardware features are not thread safe. Those non thread-safe features could be used in a single task, or somehow protected using a semaphore. The PIC24E is supported after all.


dsPIC33E port

Posted by dragonflight1 on February 6, 2015

There is a bit more to it than that. It needs to be added to portasm_dsPIC.S, should probably not bother saving DO resisters, it has EDS (different registers), so requires several changes in port.c

mike PS. At the same time port.c should remove its dependence on MPLAB i.e. #ifdef MPLABDSPICPORT should be changed to #ifdef __DSP__

PPS Martin Hollenweger had a minimal change port to support PIC33E http://interactive.freertos.org/entries/27667473-FreeRTOS-V-7-5-2-port-for-dsPIC33E-max-32KB-RAM- Or if really bold, you could use a variant of mine - eliminates the asm files and I would be happy to remove the hardware stack checking or make it conditional so there would be no operational difference


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

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Meet us at Embedded World. Hall 3A-525.

Hear from Richard Barry at Embedded World. Feb 28, 16:00, Hall 4-428.

Video: Watch James Gosling & Richard Barry at re:Invent, Las Vegas 2017.

FreeRTOS kernel V10.0.1 is available for immediate download. Now MIT licensed.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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

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

OpenRTOS and SafeRTOS