Homepage | FAQ
FreeRTOS FAQ - Memory and Memory Management
How much RAM does FreeRTOS use?
Why do queues use that much RAM?
How much ROM does FreeRTOS use?
How can I reduce the amount of RAM used?
How is RAM allocated to tasks?
How is RAM allocated to queues?
How big should a task stack be?
FAQ Top
How much RAM does FreeRTOS use?
This depends on your application. Below is a guide based on:
- IAR STR71x ARM7 port.
- Full optimisation.
- All components other than co-routines and trace compiled in.
- Four priorities.
| Item |
Bytes Used |
| Scheduler Itself |
236 bytes (can easily be reduced by using smaller data types). |
| For each queue you create, add |
76 bytes + queue storage area (see FAQ Why do queues use that much RAM?) |
| For each task you create, add |
64 bytes (includes 4 characters for the task name) + the task stack size. |
Note these figures are much lower for 8 and 16 bit architectures!
Why do queues use that much RAM?
Event management is built into the queue functionality. This means the queue data structures contain all the RAM that other RTOS
systems sometimes allocate separately. There is no concept of an event control block within FreeRTOS.
How much ROM does FreeRTOS use?
This depends on your compiler and architecture.
The kernel itself required under 4KBytes of ROM space when using the same configuration as stated for the FAQ "How much RAM does FreeRTOS use?".
How can I reduce the amount of RAM used?
- Set configMAX_PRIORITIES and configMINIMAL_STACK_SIZE (found in portmacro.h) to the minimum values acceptable to your application.
- If supported by the compiler - define task functions and main() as "naked". This prevents the compiler saving registers to the
stack when the function is entered. As the function will never be exited the registers will never get restored and are not
required.
- Recover the stack used by main(). The stack used upon program entry is not required once the scheduler has
been started (unless your application calls vTaskEndScheduler(), which is only supported directly in the distribution for
the PC and Flashlite ports). Every task has it's own stack allocated so the stack allocated to main() is available for reuse once
the scheduler has started.
- Minimise the stack used by main(). The idle task is automatically created when you create the first application task.
The stack used upon program entry (before the scheduler has started) must therefore be large enough for a nested call to
xTaskCreate(). Creating the idle task manually can half this stack requirement. To create the idle task manually:
- Locate the function prvInitialiseTaskLists() in Source\tasks.c.
- The idle task is created at the bottom of the function by a call to xTaskCreate(). Cut this line from Source\tasks.c
and paste it into main().
- Rationalise the number of tasks. The idle task is not required if:
- Your application has a task that never blocks, and ...
- Your application does not make any calls to vTaskDelete().
- Reduce the data size used by the definition portBASE_TYPE (this can increase execution time).
- There are other minor tweaks that can be performed (for example the task priority queues don't require event management), but if you get
down to this level - you need more RAM!
How is RAM allocated to tasks?
To create a task the kernel makes two calls to pvPortMalloc(). The first allocates the task control block, the second allocates
the task stack.
Please read the memory configuration section of the API documentation for details of the allocation scheme.
How is RAM allocated to queues?
To create a queue the kernel makes two calls to pvPortMalloc(). The first allocates the queue structure, the second the queue storage
area (the size of which is a parameter to xQueueCreate()).
How big should the stack be?
This is completely application dependent, and not always easy to calculate. It depends on the function call depth, number of local variables
allocated, number of parameters in function calls made, interrupt stack requirements, etc. The stack must always be large enough
to contain the execution context (all the processor registers).
The stack of each task is filled with 0xa5 bytes upon creation which allows the high water mark to be viewed using suitable debugging tools.
Also see the function usPortCheckFreeStackSpace() implemented in the x86 port for an example of how the high watermark can be measured.
Copyright (C) 2003 - 2008 Richard Barry
Any and all data, files, source code, html content and documentation included in the FreeRTOS distribution or available on this site are the exclusive property of Richard Barry.
See the files license.txt (included in the distribution) and this
copyright notice for more information. FreeRTOS
TM and FreeRTOS.org
TM are trade marks of Richard Barry.