Hi
I wonder that anyone working on FreeRTOS with dsPIC33EP series.
Because I searched forums and they said freertos doesnt support some dsPIC families. Users are trying to convert dsPIC33F  port and memory mapping registers to dsPIC33EP.
But they didn’t success.
So is there anyone working on dspic33ep?
 
Thank you.

Sorry – there is no update on this since: http://www.freertos.org/FreeRTOS_Support_Forum_Archive/March_2013/freertos_dspic33ep512mu810_and_freertos_7067904.html Regards.

It looks like it shouldn’t be too hard to make the port for someone who knows a little bit about writing ports for FreeRTOS, understand the architecture of the dsPic33EP  series, has a little bit of time, and some hardware to test on. Currently I am short of the latter too, or I would probably be working on this. From what I know of the processor, it shouldn’t be too hard for someone who knows it to make the needed change.

I’m having the same problem with a new HW (based on dsPIC33EP128MC506). it seems quit easy to update port.c and portasm_dsPIC.c to support the new registers. The problem are the DO Loop register (DCOUNT, DOSTART, DOEND), they have changed from simple registers (with shadow register) to a 4-Level Hardware Stack. It seems that it’s not possible to save that stack! I think that the only solution is to not use the DO instruction (I have to check if the XC16 compiler is using it or not) for code under RTOS control. I will do some tests and report back my results. P.s. I think that we have the same problem when two tasks are using push.s and pop.s as we do not save the shadow registers.

Hi, Interesting to see that others struggle hardly with this as well. Please refer to this link, what I already achieved, but my test project it is still crashing when yielding: https://sourceforge.net/p/freertos/discussion/382005/thread/7d32a74f Nice idea to look for the do-loop stack regarding compiler options which I already had in mind too but did not have time. I’ll go and check this as well. @ Martin, if you can go further as well please let me know.

Hi Heiko, I have my port running. For my dsPIC33E it was very easy, as I don’t have more then 32K of RAM (so I don’t need eds pointers).But I’m still waiting for confirm (from Microchip) that the XC16 don’t use the DO assembler instruction. Attached You can find the only two files I changed. Martin

Hi Martin, just got something running today as well and before I checked your post 😉 EDS should not be a problem, my main concern would be the do loop handling. I compiled my bigger project with c30 3.31 without Opt and O3, in the list file the DO Loop was not found after compiling, so I hope for the moment – that this will be no problem. There is also an option to “unroll do loops” for the compiler. perhaps this will help as well. What I faced today was that I was looking for a fault al the time which actually did not exist. The Simulator in MPLAB 8 was messing up and did not multiply for the e-Type properly. So it caculated in assembly code (array access) 3*10 = 60 instead of 30, on F-type same code was working. So the access to the lists failed totally. In the silicon this fault does not come up, the multiply is working as it should. My changes look similar to yours so I think we are on the right way. best Heiko

Today I go the answer from Microchip (thank to Benjamin): The XC16 compile don’t use the DO Instruction. So I think that my dsPIC33E port is save as long as I: – Do not use the DO instruction in some assembler code. – Do not use the shadow register. ( attribute(interrupt , shadow) is not allowed) – Do not use eds memory (limiting the RAM to 32 KByte) P.s. The DO instructions and the shadow registers are allowed if used in IRQ functions that are on interrupt levels that are not under RTOS control (configKERNELINTERRUPTPRIORITY). Richard, can You confirm my findings, if it’s OK I will put my port under “Contributed Source Code” regards Martin

I can’t confirm your findings without going through the details in the manuals myself – but I think you know more about it than I do. Yes – please upload your code to the Interactive site. Regards.

OK Port added on FreeRTOS Interactive Regards Martin

An update on the DO instruction. As I noted on FreeRTOS Interactive the math libraries are likely to use the DO instructions. I did verify that some of them use up to 2 levels (for things like IIfs and matrix stuff). The 33Es have a 4 level stack so you’re probably safe if you only have 1 or 2 tasks using the dsp libraries or use mutexs/semaphores to guard the calls. Also I have yet to verify it (I need to try non 33e dsp processor), but I believe the documentation indicates a limit of 7/8 levels for the DOs on the dsPIC30s and dsPIC33Fs as there is a 3 bit level register and it doesn’t specify if it wraps or saturates. So, the 4 levels may not be that much more restrictive. Also there is nothing wrong with using the EDS memory for the application code, but it is a really bad idea to even contemplate using it for stack. It can’t be used by FreeRTOS, but you can pass pointers to it with queues and the like. mike