The port for MPLABPIC24dsPIC from FreeRTOS v8.2.1 uses a deprecated define “MPLABDSPIC_PORT” in file “port.c”, function “pxPortInitialiseStack” which needs to be defined for the port to work. To get it to work, either 1) #define MPLABDSPICPORT 2) or remove the two lines #ifdef MPLABDSPICPORT #endif The code should probably be cleaned up to remove the reference to MPLABDSPICPORT.

MPLABDSPICPORT is a FreeRTOS definition that is set in the build configuration within MPLAB. It is not deprecated. For whatever historic reason, the FreeRTOS PIC24 and dsPIC ports use the same port.c source file, and that definition is used to save additional registers when it is built for use with a dsPIC. Why do you think this is a bug? Regards.

I’m betting (now don’t you dare let any pesky facts interfere, lol) that MPLABDSPICPORT is used by the newer MPLAB X/Eclipse IDE to allow older MPLAB code to work unmodified…along the lines of some of the earlier ways that config registers were set from within the source code, for example. It will be a few days of other distractions before I can prove my case.

Looking again, I think I understand Clark’s original comments now. Really old versions of FreeRTOS needed a constant to be defined to allow the kernel code to pull in the header files that were correct for the port being used. That scheme was scrapped some time ago in favour of simply updating the compiler’s include path to include the correct constant – but the constants themselves were kept in the header files for backward compatibility – until the last release when they were moved to a header fle called deprecateddefinitions.h. Although depricateddefinitions.h is included automatically, there is a comment saying the definitions in the file should no longer be used…. ….however for the PIC24/dsPIC port (and only that port, as far as I know) the definition is still used for the reason stated in my previous post in this thread. So for that port, the comment is not correct – but the demo project in the FreeRTOS download should still build ok. Regards.

It should be possible to check on some of the other symbols that the compiler defines to determine the chip family being used.

It should be possible to check on some of the other symbols that the compiler defines to determine the chip family being used.

The compiler has ifdef defined for each processor and each family group.

The core kernel code should not, ideally, check for individual chips, as it would be a maintenance nightmare. Calling a macro defined in the Microchip header files is find, as it is then up to the Microchip header files to ensure the correct version of the macro is used for the correct chip. Regards.

It has been a bit since I used it, but as I remember the Microchip compiler defines both a symbol for the specific chip, and a symbol for the family (something like PIC24F or dsPIC33). These symbols could be used by the port layer to determine the exact code to use. These are not defined in a header, but automatically added when you select the chip in the project options.