clarkdailey wrote on Tuesday, August 11, 2015:
The port for MPLAB\PIC24_dsPIC from FreeRTOS v8.2.1 uses a deprecated define “MPLAB_DSPIC_PORT”
in file “port.c”, function “pxPortInitialiseStack” which needs to be defined for the port to work.
To get it to work, either
rtel wrote on Tuesday, August 11, 2015:
MPLAB_DSPIC_PORT 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.
e-christenson wrote on Wednesday, August 12, 2015:
I’m betting (now don’t you dare let any pesky facts interfere, lol) that MPLAB_DSPIC_PORT 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.
rtel wrote on Wednesday, August 12, 2015:
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 deprecated_definitions.h. Although depricated_definitions.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.
richard_damon wrote on Thursday, August 13, 2015:
It should be possible to check on some of the other symbols that the compiler defines to determine the chip family being used.
richard_damon wrote on Thursday, August 13, 2015:
It should be possible to check on some of the other symbols that the compiler defines to determine the chip family being used.
tlafleur wrote on Thursday, August 13, 2015:
The compiler has ifdef defined for each processor and each family group.
rtel wrote on Friday, August 14, 2015:
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.
richard_damon wrote on Friday, August 14, 2015:
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.