This is a subsection of the full FAQ
Statistics:
Related FAQs:
This depends on your application. Below is a guide based on:
| 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. |
This depends on your compiler, architecture, and RTOS kernel configuration.
The RTOS kernel itself required about 5 to 10 KBytes of ROM space when using the same configuration as stated for the FAQ "How much RAM does FreeRTOS use?".
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 RTOS 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 RTOS 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 RTOS scheduler being started.
By way of example, on a ARM 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 RTOS scheduler being started.
By way of example, on a ARM 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 RTOS scheduler. |
The RTOS 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 ARM Cortex-M3 device, using the ARM RVDS compiler with optimization set to 1 (low), starting the RTOS scheduler will take approximately 1200 CPU cycles. |
Context switch times are dependent on the port, compiler and configuration. A context switch time of 84 CPU cycles was obtained under the following test conditions:
Notes:
Three of the example memory allocation schemes supplied with FreeRTOS allocate memory from a statically allocated array that is dimensioned by the configTOTAL_HEAP_SIZE constant in FreeRTOSConfig.h. These are just normal statically allocated arrays, and therefore appear in the RAM usage figures provided by many tool chains. The tool chain is in effect showing the heap as consumed RAM, even though at that point the heap is completely free as no memory has actually been allocated.
C applications require some RAM for things like static variables, buffers, etc. but will rarely use all the RAM available on a microcontroller. Many of the FreeRTOS demo applications dimension the heap to use up all the RAM that is left over, making it appear as if the application is using all the RAM available.
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.
The quoted ROM/Flash footprint figures are genuine. If you write a tiny FreeRTOS test program and it appears to consume more ROM than expected then it is probably because of the libraries that are being included in your build, not because of FreeRTOS. In particular, GCC string handling and any floating point library is going to bloat your code.
FreeRTOS includes a very cut down open source implementation of many string handling functions in a file called printf-stdarg.c. Including this in your project can greatly reduce both the amount of ROM used by the build, and the size of the stack required to be allocated to any task making a string handling library call (sprintf() for example). Note that printf-stdarg.c is open source, but not covered by the FreeRTOS license. Ensure you are happy with the license conditions stated in the file itself before use.
Also, most linkers will remove unused code by default, but the GNU linker will only remove unused code if you explicitly tell it to.
Check the output .map file to find exactly how ROM/Flash is being used.
If a task is created using the xTaskCreateStatic() API function then the RAM required by the task is provided by the application writer, and no memory allocation occurs.
If a task is created using the xTaskCreate() API function then the RAM required by the task is allocated inside the xTaskCreate() API function from the FreeRTOS heap.
The stack used by main() is not used by tasks, but (depending on the port) may be used by interrupts.
If a queue is created using the xQueueCreateStatic() API function then the RAM required by the queue is provided by the application writer, and no memory allocation occurs.
If a queue is created using the xQueueCreate() API function then the RAM required by the queue is allocated inside the xQueueCreate() API function from the FreeRTOS heap.
Tasks can be created using either the xTaskCreate() or xTaskCreateStatic() API function. The function's usStackDepth parameter specifies the size of the stack that will be allocated to the task being created (in words, not bytes!). It is common for people to ask how to determine the usStackDepth value, but, except in one way described below, there is little difference between determining how much stack is required when using an RTOS than when writing a bare metal application (an application that does not use an operating system).
Exactly as when writing a bare metal application, the amount of stack required is dependent on the following application specific parameters:
While it is not easy to determine how much stack to allocate a task, the RTOS does provide functionality that allows a task's stack size to be tuned taking a pragmatic trial and error approach; the uxTaskGetStackHighWaterMark() API function can be used to see how much stack has actually been used, allowing the stack size to be reduced if more was allocated than necessary, and the stack overflow detection features can be used to determine if a stack is too small. In addition, the stack usages of all the RTOS tasks can be viewed at once using the uxTaskGetSystemState() API function, or one of the numerous FreeRTOS aware IDE plug-ins.
The FreeRTOS download contains a demo application for each port, and the FreeRTOSConfig.h file provided with each demo application defines a constant called configMINIMAL_STACK_SIZE. It is strongly recommended to never allocate a task a stack that is smaller than the configMINIMAL_STACK_SIZE setting used in the port's demo application.
See also Erich Styger's blog post on using the GNU stack analysis tool.