Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

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.

Attachments

alternate (1203 bytes)

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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists