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

PIC24 port

Posted by dragonflight1 on October 25, 2013

I have just started using FreeRTOS and have spent the last few days fighting with eclipse, compilers ..., but have spent some time reading forums and actually playing with it working! I am using a dsPIC33EP256MC502. (I initially looked at it a couple of weeks ago - before Martin Hollenweger posted changes for the dsp24E devices)

I don't know if any one is interested, but I rewrote the port.c file to work for all (so far) of the pic24 families and not need a separate assembly files. At the same time I removed the restriction on setting the kernel priority.

Secondly, I have added code to use the hardware stack bounds check - I have seen a number of posts about this but no resolution. If this is useful, I need guidance on how to get the stack size info to the portable layer - I added a parameter to pxPortInitialiseStack. I am also interested in writing code that would use this to monitor stack usage and report how much was really used.

Thirdly, It is no longer (in the current port) necessary to use the omit-frame-pointer compiler option and so the comment should be removed from the web pages (and a good thing as the current XC16 compiler ignores the option for the 24E devices!)

I'm sure more gremlins are going to pop up, but today I am a very happy camper!


PIC24 port

Posted by richardbarry on October 27, 2013

I don't know if any one is interested, but I rewrote the port.c file to work for all (so far) of the pic24 families and not need a separate assembly files. At the same time I removed the restriction on setting the kernel priority.

Definitely of interest. Please post the files to the Interactive site too. I have removed the comment about the frame pointer (which was originally introduced to work around a compiler bug that was probably fixed many years ago) from the web page and could also add in some links to the Interactive site posts when you are happy the code is stable.

I need guidance on how to get the stack size info to the portable layer

At which point? Presumably during the context switch, as that is when the stack boundary registers would be configured.

I think the information you need is in the task control block. Once the pxCurrentTCB pointer is pointing to the task being switched in you can access pxCurrentTCB->pxEndOfStack to know the top limit. That needs to be done from C code though as its offset into the TCB will change depending on FreeRTOSConfig.h settings. You could therefore no add the code into the port layer but instead use on of the hook macros inside the tasks.c file. For example, traceTASKSWITCHEDIN.

Regards.


PIC24 port

Posted by dragonflight1 on October 27, 2013

I am happy to post the code on the interactive site, but I would like some comment on the code as there are some choices. I am a fan of complicated solutions that make it easier to make the most common changes easier, in particular doing odd things (like figure out with registers go on the stack) once instead of several points, so I have the original version of pxPortInitialiseStack as well as my preferred version. I would be totally unoffended if you would prefer the original, to mine.

As for the stack limit, the info is needed at the time the stack switch is executed in the port. I have put it on the stack (and so need the info at task creation time), so that it could be modified on the fly (e.g. make it small, and increase it (the limit) as needed - so stack usage could be profiled. Probably only small gain. To do so properly would require a new function to return stack size/limits ...

My suggestion would be to place it as the second element on the TCB (as you've already defined the first element accessible to the port layer.) I would then change it so that on stacks that grow down pxStack is the second element. I have to think other machines have hardware stack checking and this could be generally useful and requires minimal change, not affecting current ports IMHO.

For now I've changed mofifying pxPortInitialiseStack arguments to defining traceTASK_CREATE to saving the offset of pxEndOfStack in an external (or pushing it onto the stack when I get around to playing with using SPLIM to trace stack usage) and using the offset in vPortYield.

I will upload the code later this week - assuming that it stays running!

mike


PIC24 port

Posted by dragonflight1 on October 31, 2013

I have uploaded the code to the interactive site. I have used it for a week with no issues

mike


PIC24 port

Posted by hollenweger on November 4, 2013

Hello Mike,

Thank You for your code, I will try your very nice Port. I have noted that You don't save the DO registers on dsPIC33E platforms, I thick this is OK (in any case I don't now a possibility to save the HW stack used). Be award that You can used the DO instruction only in one Task and/or in Interrupts. As You have mentioned in a other post the DO instruction is used by the DSP library, but not by the C-Compiler, so it's you responsibility to use the DSP library functions in a safe way.

Martin


[ 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