I am using freertos 5.0. I am using MPLAB 8.10, dspic33 and C30 3.10 from Microchip. armag1234 raised the issue with -fomit-frame-pointers in http://sourceforge.net/forum/forum.php?thread_id=1888310&forum_id=382005 for which I had asked for my info. But no reply… So, I will ask the group these questions: 1. Why must -fomit-frame-pointers be used for freertos compilation? It seems to me that if there is a need to decouple the gcc frame pointer for freertos so it can perform context switching then why is this option ONLY set for the specific freertos module(s) that deal with the switch? 2. Better yet, since the context switch is so important, especially for speed why don’t we have the context switch module in an assembler module? (I could write one if that would help.) 3. Do we have to use -fomit-frame-pointers on ALL our gcc modules in the entire load? If so, why (see Q1). 4. When I use -O3 gcc optimization on the freertos src the system acts strangely. I’m still looking in to why… Does anyone have any input on this? thanks, rich

Q1 and 3. That would be for Richard to answer. Q2. This is just a portability thing. It would not be possible to maintain assembly code that would be different for every port. Currently only the push pop of registers is in assembly code. Q4. The PIC32 port works fine at -O3, sorry I cannot comment on the dsPIC port.

This is from memory, I would have to double check. The context switch in the PIC24 port is quite simple and just uses a function call.  The way the function exits has to be identical to the way interrupts exit (for the most part).  If the frame pointer is used the function epilogue code changes, meaning the exit code no longer matches that used in interrupts.  You might get away with just port.c using the -f-omit-frame-pointer option.  Try it and see.  The other alternative would be to use an assembly file instead of a C file for the yield function so you control the code exactly, this would remove the need (I think) for the -fomit-frame-pointer flag altogether. Regards.