Quality RTOS & Embedded Software

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




Loading

nested function calls and memory usage

Posted by Magnus Kriel on January 9, 2013
If I have a task with local variables, these variables are also stored on the task's stack right?
If I call a function in this task( function_A ), which has local non-static variables, will these variables also be allocated from the task's stack? And what if function_A calls function_B which has also non-static variables?

Thanks.

RE: nested function calls and memory usage

Posted by Richard on January 9, 2013
Tasks are just C functions. The compiler knows nothing about the kernel or how the tasks will run and allocates non static local variables to either the task stack or registers (depending on the compiler and optimisation level) just as if the functions were called from main() before the scheduler was started.

Remember that each task has its own stack, so the variables that are on the stack are only seem by that task.

Regards.

RE: nested function calls and memory usage

Posted by Magnus Kriel on January 9, 2013
Ok,

Just to get more clarity:

Does the local non static memory form part of the task context?
portRESTORE_CONTEXT() and portSAVE_CONTEXT() only pops and pushes the processor registers. The local variables are preserved in the task's stack when the task is switched out by another task?
Any other functions which are called within the task is handled as per normal(kernel has no influance on the local variables of those functions ; these variables are located on the main heap)?

RE: nested function calls and memory usage

Posted by Magnus Kriel on January 9, 2013
Sorry, made a typo in my previous reply(see bold text below):

Does the local non static variables form part of the task context? portRESTORE_CONTEXT() and portSAVE_CONTEXT() only pops and pushes the processor registers. The local variables are preserved in the task's stack when the task is switched out by another task?
Any other functions which are called within the task is handled as per normal(kernel has no influance on the local variables of those functions ; these variables are located on the main heap)?

RE: nested function calls and memory usage

Posted by Richard on January 9, 2013
The stack variable are indirectly part of the the task context because the stack pointer is one of the registers saved by portSAVE_CONTEXT() and restored by portRESTORE_CONTEXT().

If a task places variables (local non static variables) on the stack, gets switched out, then gets switched back in again, its execution context will not have changed - everything will be exactly as it was when it was switched out - including the variables on its stack. If another task runs the stack pointer will have been moved to point to the stack (and variables on the stack) that is unique to that task. [this applies to non-static variables only]

“ these variables are located on the main heap”

Only memory allocated by malloc() [pvPortMalloc() in FreeRTOS case] uses the heap - whether you have an RTOS or not.

Regards.

RE: nested function calls and memory usage

Posted by Richard Damon on January 10, 2013
One other thing to note, that co-routines are a different beast, as co-routines share the stack, and have a bunch of special rules on how to implement themselves (and what context get saved between switches).

RE: nested function calls and memory usage

Posted by Magnus Kriel on January 10, 2013
Thanks for all the info. I have some clarity now.


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




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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