I have just started using FreeRTOS and have spent the last few days fighting with eclipse, compilers …, but have spent some time reading forums and actually playing with it working! I am using a dsPIC33EP256MC502. (I initially looked at it a couple of weeks ago – before Martin Hollenweger posted changes for the dsp24E devices) I don’t know if any one is interested, but I rewrote the port.c file to work for all (so far) of the pic24 families and not need a separate assembly files. At the same time I removed the restriction on setting the kernel priority. Secondly, I have added code to use the hardware stack bounds check – I have seen a number of posts about this but no resolution. If this is useful, I need guidance on how to get the stack size info to the portable layer – I added a parameter to pxPortInitialiseStack. I am also interested in writing code that would use this to monitor stack usage and report how much was really used. Thirdly, It is no longer (in the current port) necessary to use the omit-frame-pointer compiler option and so the comment should be removed from the web pages (and a good thing as the current XC16 compiler ignores the option for the 24E devices!) I’m sure more gremlins are going to pop up, but today I am a very happy camper!

I don’t know if any one is interested, but I rewrote the port.c file to work for all (so far) of the pic24 families and not need a separate assembly files. At the same time I removed the restriction on setting the kernel priority.

Definitely of interest. Please post the files to the Interactive site too. I have removed the comment about the frame pointer (which was originally introduced to work around a compiler bug that was probably fixed many years ago) from the web page and could also add in some links to the Interactive site posts when you are happy the code is stable.

I need guidance on how to get the stack size info to the portable layer

At which point? Presumably during the context switch, as that is when the stack boundary registers would be configured. I think the information you need is in the task control block. Once the pxCurrentTCB pointer is pointing to the task being switched in you can access pxCurrentTCB->pxEndOfStack to know the top limit. That needs to be done from C code though as its offset into the TCB will change depending on FreeRTOSConfig.h settings. You could therefore no add the code into the port layer but instead use on of the hook macros inside the tasks.c file. For example, traceTASKSWITCHEDIN. Regards.

I am happy to post the code on the interactive site, but I would like some comment on the code as there are some choices. I am a fan of complicated solutions that make it easier to make the most common changes easier, in particular doing odd things (like figure out with registers go on the stack) once instead of several points, so I have the original version of pxPortInitialiseStack as well as my preferred version. I would be totally unoffended if you would prefer the original, to mine. As for the stack limit, the info is needed at the time the stack switch is executed in the port. I have put it on the stack (and so need the info at task creation time), so that it could be modified on the fly (e.g. make it small, and increase it (the limit) as needed – so stack usage could be profiled. Probably only small gain. To do so properly would require a new function to return stack size/limits … My suggestion would be to place it as the second element on the TCB (as you’ve already defined the first element accessible to the port layer.) I would then change it so that on stacks that grow down pxStack is the second element. I have to think other machines have hardware stack checking and this could be generally useful and requires minimal change, not affecting current ports IMHO. For now I’ve changed mofifying pxPortInitialiseStack arguments to defining traceTASK_CREATE to saving the offset of pxEndOfStack in an external (or pushing it onto the stack when I get around to playing with using SPLIM to trace stack usage) and using the offset in vPortYield. I will upload the code later this week – assuming that it stays running! mike

I have uploaded the code to the interactive site. I have used it for a week with no issues mike

Hello Mike, Thank You for your code, I will try your very nice Port. I have noted that You don’t save the DO registers on dsPIC33E platforms, I thick this is OK (in any case I don’t now a possibility to save the HW stack used). Be award that You can used the DO instruction only in one Task and/or in Interrupts. As You have mentioned in a other post the DO instruction is used by the DSP library, but not by the C-Compiler, so it’s you responsibility to use the DSP library functions in a safe way. Martin