Richard/rtel,

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)

mike

Other than the

#error

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.

Regards.

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

mike