FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [August 2015 Threads] FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by clarkdailey on August 11, 2015 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.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by rtel on August 11, 2015 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.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by e-christenson on August 12, 2015 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.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by rtel on 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 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.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by richard_damon on 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.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by richard_damon on 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.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by tlafleur on August 13, 2015 The compiler has ifdef defined for each processor and each family group.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by rtel on 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.
FreeRTOS v8.2.1 bug in dsPIC33F port.c pxPortInitialiseStack( ) Posted by richard_damon on 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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|