FreeRTOS can best be described as a popular real-time operating system for embedded devices, including Atmel’s SAM4L ARM Cortex-M4 MCU (microcontroller). The real-time operating system is succinct, as it consists of three or four C files, and is written primarily in the same language.
So why use an RTOS? Well, a real-time operating system for embedded devices offers a wide variety of benefits, including an optimized design with cleaner interfaces, the ability to reuse code and the opportunity to benefit from low-power operation.
Applications coded to take advantage of an RTOS are designated as a set of of autonomous, communicating threads of execution. Specifically, in FreeRTOS each thread of execution is known as a task, with each typically spending varying degrees of time waiting for an event.
As Richard Barry of FreeRTOS explains, a task may have to wait for an interrupt, a time period to expire, or a message from another task.
“In FreeRTOS a task that is waiting for something to happen is said to be in the blocked state. An RTOS scheduler will not run a task that is in the blocked state. When all the tasks that were created by the application are in the blocked state the RTOS scheduler will run a task called the idle task, which is created by the RTOS itself,” Barry wrote in a recent blog post published on EE Times Embedded.
“An RTOS therefore provides a very convenient and automatic way of knowing when the application is idle, and therefore when the microcontroller on which the application is running can be placed into a low-power state.”
Indeed, FreeRTOS allows an app writer to add their own into the idle task via the definition of an idle task callback or hook function. It is therefore quite common to reduce the power consumed by the microcontroller on which FreeRTOS is running by exploiting the idle task callback to switch the microcontroller into a low power state.
However, the resulting power saving achieved by the above-mentioned method is limited if the RTOS requires a periodic exit of the low power state to process tick interrupts (periodic interrupts used by an RTOS to track time). Meaning, any energy savings will be outweighed if the frequency of the tick interrupt is excessive – for all but the lightest power saving modes.
Enter the FreeRTOS tickless idle mode, which halts (or suppresses) the periodic tick interrupt when the idle task is executing, subsequently making a correcting adjustment to the time maintained by the RTOS when the tick interrupt is restarted. This allows the microcontroller to remain in a deep power saving state until an interrupt occurs or the RTOS kernel transitions a task out of the blocked state.
“There is a run-time overhead associated with suppressing the tick interrupt: the peripheral used to generate the periodic tick must be reprogrammed before entering the low-power state, and again when exiting the low power state,” said Barry.
“For this reason, and to ensure correct processor time sharing between tasks of equal priority, the tick interrupt is not suppressed unless all the application tasks are in the blocked state.”
The tick suppression feature supported by FreeRTOS can perhaps be best illustrated by Atmel’s SAM4L ARM Cortex-M4 microcontroller, which is specifically designed for low power applications.
As you can see in the image below, the SAM4L evaluation kit (SAM4L-EK) includes a board monitor that displays the amount of current consumed by the microcontroller as it executes applications.
This particular image is a photograph of the board monitor display captured when the microcontroller was executing a simple FreeRTOS demo with the optional tick suppression feature enabled – clearly spending the majority of its time in the special retention low power mode of the SAM4L.
“The current readings taken when in retention mode resulted in the flat horizontal line visible along the bottom of the graph in the photograph. Every 500 and 500 + 20 milliseconds an application task briefly left the blocked state to perform a trivial piece of processing,” Barry noted.
“The current readings taken when an application task was executing resulted in the two small dots that appear four times on the graph above (the measurement resolution and screen resolution make the dots appear almost as one elongated dot). As four execution instances are visible on the graph it can be seen that the graph in the photograph covers a two second period.”