dspic33ep512mu810 and freertos

doonster wrote on Monday, March 18, 2013:

I need some guidance to port freertos to dspic33ep. I have read all I can find in docs and forums, to no avail….
I can successfully build using the dspic33Fxxxxxx, but not using the dspic33E. I am using MPLAB X, the latest version of FreeRTOS v7.4, X16 compiler, dspic33E USB starter kit on I/O expansion board, and ICD 3.

I have successfully used freeRTOS with pic32, but my knowledge is limited.

If someone could give me some direction, I would greatly appreciate it…


richard_damon wrote on Monday, March 18, 2013:

The current port for the 16 bit PICS (PIC24 and dsPIC) doesn’t have support for the E series with extended memory (as I remember, and the fact you are asking says it is probably still true). The difference between the F families and the E families is a change in the memory mapping registers.

All that should be needed is to (via an ifdef or something similar) change the saving/restoring of the memory mapping register and add the needed data into the initial stack frame code.

doonster wrote on Monday, March 18, 2013:

Thanks Richard for such a quick reply….

unfortunatly, I’m not sure which file those would be, that need altering….for I have never gotten so deep as to altering RTOS files……I guess my knowledge is extremly limited!

Can you direct me to any source material that may have directions and/or examples?

A “hand holding approach” would probably work best for me, are there any avenues for such?

Thank you,
best regards,

rtel wrote on Monday, March 18, 2013:

Actually, FreeRTOS V7.4.0 does have support for the E series for PIC24, but not dsPIC as I wasn’t quite sure what else was needed on the dsPIC parts.

The PIC24 port layer should swap automatically between the E and F parts if you are using the latest microchip compiler (XC).  If you look at the port layer files (C and asm) you will see how this is done as the code uses the preprocessor to check for a definition that is provided by the compiler itself.


doonster wrote on Tuesday, March 19, 2013:

Thank you Mr. Barry,

I have and will go back and look at those files again, to see if I can get things to build for the 33E. If not, maybe licensure should be the next approach to abtain further assistance.
Again, thanks for the timely responses, and a worthy forum.


doonster wrote on Wednesday, March 20, 2013:

Hello again,

Mr. Barry or whom ever,

I added and/or changed the port.c and portasm.s files as described in “FreeRTOS for dspic33ep512mu810” forum topic,
but still does not build……also included <d33ep512mu810.h> in FreeRTOSconfig file. At this point I have two errors stemming from CNPU2bits undeclared.

Do I need to change the .gld file or add .gld file for xxx33epxxxx?
There is no .gld file for xxxx33epxxx, as I have checked.

Thanks in advance,

doonster wrote on Wednesday, March 20, 2013:

adding to my own post…….I did find the 33epxxxx,gld file, I guess the Win7 C drive search is useless……
for anyone else reading this, they are located in Programfiles(x86)\microchip\xc16\v1.11\support\dspic33e\gld\xxxxxxxx

Even by replacing the 33fxxx.gld w/ 33epxxx.gld file, the above posted errors still remain.

edwards3 wrote on Wednesday, March 20, 2013:

Well if you have the right header file for the part you are using included and CNPU2bits is not defined it must mean that whatever the CNPU2 is, its not present on the part you are porting too.

richard_damon wrote on Wednesday, March 20, 2013:

Looking at the header file, I think you have the wrong names for the Pull Up ports. It looks that this series calls the ports CNPUx where x is the letter for the port register the pin is connected to, not having generic CNPU1 for the first 16 CN pins and CNPU2 for the next 16 CN pins.

doonster wrote on Wednesday, March 20, 2013:

Thanks edwards3,

Yes, that is obvious, even to me……when I comment them out, I then get a another whole set of errors, and more numerous.
I understand that CNPU2 is change notification for p33fxxx and being different than p33epxxxxx. CN should be disabled by default anyway, so commenting out should have no effect, why that leads to even more errors is beyond my understanding of MPLAB….

If I’m missing a subtle point, let me know.

doonster wrote on Wednesday, March 20, 2013:

After reading richard_damon’s post, thanks by the way, I am wondering if I should start ripping out the un-neccesary code such as, timertest.c,serial.c,Partest.c and Icd.c? It’s not important to get the demo working, for I do not have the exp16 board anyway. My intent is to get the very basic build for the p33epxxx hardware. I was just trying to follow the general discussions to port over………I don’t want to waste peoples’ time….
“cali2houston” posed this same problem in the forum, but unfortunatelly the solution was not uploaded.

Do you think this would be a better approach? thus simplifying the help needed….

davedoors wrote on Thursday, March 21, 2013:

Do you have the code building for your target without FreeRTOS included? I would suggest starting with a known good project for your hardware, with all the headers included, and when that is building add in the FreeRTOS code.

doonster wrote on Thursday, March 21, 2013:

Thanks davedoors for your suggestion,
Yes I do, a simple turn on some leds and remap of a couple of pins to Tune the FRC(internal osc. for pic) to around 64MHz.
Thus verifying my hardware, ICD3 etc.
I think Mr. Barry, as posted, has indicated the direction needed, but I am unable to impliment without  explicit outline. My bad.