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

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 ]    [ 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