FreeRTOS FAQ - Memory Usage and Boot Times

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?
How Long does FreeRTOS take to boot?

FAQ Top

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.

Note these figures are much lower for 8 and 16 bit architectures!

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.

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?".

• 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:
  1. Locate the function prvInitialiseTaskLists() in Source\tasks.c.
  2. 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:
  1. Your application has a task that never blocks, and ...
  2. 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!

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.

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()).

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.

FreeRTOS, OpenRTOS and in most cases SafeRTOS are supplied as source code for static linking into the users application. The build process therefore results in a single executable binary image. Typically such an image will include a C start up routine to set up the C run time environment, before calling main() to execute the users application. The interrupt vector table will also be statically configured and included at a predetermined location within the same binary.

The table below provides an indication of the sequence of processing booting such a system will require, along with some guidance on the time required for this processing to complete. Note that any numbers provided are indicative only and realistic. Actual times achievable will depend on the architecture being used, the clock frequencies configured, and the configuration of the memory interface.

#	Description	Timing
1	Configure the CPU clocks for the performance level required.	Typically requires a few register writes, followed by a short delay for clocks to lock. This will take in the order of a few microseconds, depending on the architecture being used. This is an optional step. It could be performed later from C code but can boost the boot time if it is performed prior to initializing memory.
2	Initialize static and global variables that contain only the value zero (bss).	Including FreeRTOS in an application would typically only add an extra couple of hundred write accesses to be performed within a very tight assembly loop. This will add in the region of a few microseconds to the time taken when compared to that taken were the kernel not included.
3	Initialize variables that contain a value other than zero.	Including FreeRTOS in an application would typically not add any extra time to this step.
4	Perform any other hardware set up required.	Often it is desirable to configure peripherals prior to starting the scheduler. How long this takes will depend on the complexity of the peripherals being used, but on the class of microcontroller targeted by FreeRTOS the total time would typically require a few milliseconds only.
5	Create application queues, semaphores and mutexes.	Typically the majority of queues, semaphores and mutexes will be created prior to the scheduler being started. By way of example, on a Cortex-M3 device, using the ARM RVDS compiler with optimization set to 1 (low), creating a queue, semaphore or mutex will take approximately 500 CPU cycles.
6	Create application tasks.	Typically the majority of tasks will be created prior to the scheduler being started. By way of example, on a Cortex-M3 device, using the ARM RVDS compiler with optimization set to 1 (low), creating each task will take approximately 1100 CPU cycles.
7	Start the scheduler.	The scheduler is started by calling vTaskStartScheduler(). The start up process includes configuring the tick interrupt, creating the idle task, and then restoring the context of the first task to run. By way of example, on a Cortex-M3 device, using the ARM RVDS compiler with optimization set to 1 (low), starting the scheduler will take approximately 1200 CPU cycles.