Quality RTOS & Embedded Software

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


Loading

Stack depth

Posted by Grigore-Mihai Dobra on February 25, 2009
Are there any metrics to know the maximum stack depth of freeRTOS, provided that all the parameters are passed on the stack and not in registers?

I mean, which is the maximum stack usage of the longest call chain of the freeRTOS functions?

RE: Stack depth

Posted by MEdwards on February 25, 2009
The configMINIMAL_STACK_SIZE setting is a good indication. This is the stack size allocated to the idle task (which does not use much stack at all) but also most of the demo tasks. The demo tasks exercise all the FreeRTOS functions.

RE: Stack depth

Posted by Grigore-Mihai Dobra on February 26, 2009
Ok, but the idle task does not use much of the freeRTOS services, so it is unlikely that it will use the maximum stack size needed by the most task consuming kernel service.

So, if all the parameters to the freeRTOS service functions are passed on the stack, and further, all the parameters from the service to internal functions are again passed on the stack, which, in turn, allocate local variables on the stack... Is there any way to know which is the longest or the most stack-consuming call chain given these hypotheses?

My compiler is capable of passing some of the parameters in registers(up to 8 bytes), but due to the need of interfacing user-mode application with the system-mode kernel through a trap I cannot use register calling convention, but instead I need to use the stack.

So, for example, I call xTaskCreate, passing its parameters on the stack. This function stores local variables on the stack but it also calls other functions, which will further load the stack.

Of course, the size of the return addresses are architecture dependent, so there is practically no way to include them in the stack usage estimation. All I'm interested in is the size taken by the parameters and local variables.

RE: Stack depth

Posted by Dave on February 26, 2009
> Ok, but the idle task does not use much of the freeRTOS
> services, so it is unlikely that it will use the maximum
> stack size needed by the most task consuming kernel service.


Agreed, but I think the main point of edwards3 post is that the demo app tasks also use this as the stack size and these use all the FreeRTOS services.

RE: Stack depth

Posted by Grigore-Mihai Dobra on February 26, 2009
Ok, so I'll just have to look for the configMINIMAL_STACK_SIZE of an architecture similar to mine(NXP 51XA) and then do some probabilistic/statistic/estimatory math.

RE: Stack depth

Posted by incrediball on February 26, 2009
Alternatively you could create stack sizes that are easily large enough, run the program with the stack highwater function enabled, throw everything imaginable at your program and after you're satisfied that the program has run long enough, look at how much stack has been used. Using these results you can then fine tune the stack sizes.

I know this approach is not 100% sure but there are problems with calculating it out on a theoretical basis:

1. Mistakes are easily made and certain factors (e.g. interrupts) can be overlooked. I wouldn't trust a calculation unless I can perform such a test run and get comparable results.

2. You cannot make any changes to your program, or ever upgrade to a new version of FreeRTOS, without having to recalculate everything.


[ 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