Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

portRESTORE_CONTEXT

Posted by kurator on July 3, 2009
Hi,
I want to renew our STR71X GCC port.
It's been a while since I drilled down so deep into FreeRTOS ;-)
Looking at the STR75x port there are no portRESTORE_CONTEXT and
portSAVE_CONTEXT macros in portmacro.h.
Instead they are in the assembler startup code and called before evey irq.
Also the IRQ functions are declared as normal C-functions and don't need
the portSAVE_CONTEXT portRESTOR_CONTEXT macros.
There is a difference in speed mentioned somewhere.
Are there any other differences to consider?
What would be the best option to choose?
I want to use the port for gcc only and for Rowley Crossworks.
Thanks

RE: portRESTORE_CONTEXT

Posted by Richard on July 3, 2009
There are two approaches to saving and restoring the context on ARM7 (and other) architectures, different demos demonstrate the different methods, but you are free to choose whichever best suits your needs.

Method 1 configures the interrupt controller to vector directly to the handler function for the interrupting peripheral. When this is done a handler that may want to force a context switch must be written with the portSAVE/RESTORE_CONTEXT() macros inline with the syntax necessary for whichever compiler is being used (see the examples and the WEB documentation page). Interrupts that never want to cause a context switch have no special requirements and can be written as per the compiler documentation. The positive side of this method is that the save/restore overhead is only applied to interrupts that actually require it. The negative sides are greater code size (as the save/restore code is duplicated for each interrupt that requires it), and increased complexity when writing the handlers.

Method 2 configures the interrupt controller to always jump to the same vector where the context is automatically saved and restored. The interrupt controller registers are then inspected to determine the address of the handler associated with the interrupting peripheral and the handler is called. The handler can be a standard C function as the interrupt entry is already taken care of. The positives of this approach are simpler interrupt handler functions (they are just standard C functions) and smaller code size (the save/restore code is only in one place). The negative side is every interrupt has the save/restore overhead, whether it needs it or not.

Regards.

RE: portRESTORE_CONTEXT

Posted by kurator on July 15, 2009
Hi Richard,
I got my STR71x port for CrossWorks running.
It's based on the STR75x port and uses method 2 you described here.
I could send you a zip with port and demo.
From what you say in the STR75x port docs, I don't need the irq wrapper functions.
I didn't find a descreption why I need them, (Something about a gcc problem?)
and why this is the the way to do it for all future.
At least its a unnecessary jump with time and stack consumption?


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


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

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

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

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner