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] [July 2009 Threads] portRESTORE_CONTEXTPosted 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_CONTEXTPosted 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_CONTEXTPosted 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?
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|