Many embedded applications are complex enough to benefit greatly from the use of an real-time operating system (RTOS). Benefits include the ability to create a simpler, smaller, more efficient and more maintainable design, with cleaner interfaces and increased opportunities for code reuse. These are benefits that improve profitably by enabling you to bring products to market faster, and with a lower maintenance overhead. The use of an RTOS also brings with it the opportunity to benefit from simplified low-power operation.
Applications that use the services of an RTOS are designed as a set of autonomous (but communicating) threads of execution. In FreeRTOS each thread of execution is called a task . Typically, in an efficient event driven design, each task will spend a proportion of its time waiting for something to happen. For example, a task might have to wait for an interrupt, or for a time period to expire, or for 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. 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.
FreeRTOS allows the application writer to add their own code into the idle task though the definition of an idle task callback (or hook) function. It is common to reduce the power consumed by the microcontroller on which FreeRTOS is running by using the idle task callback to place the microcontroller into a low power state. The power saving that can be achieved by this basic method is however limited if the RTOS needs to periodically exit the low power state to process tick interrupts. Tick interrupts are periodic interrupts used by an RTOS to track time. If the frequency of the tick interrupt is too high, the energy and time consumed repeatedly entering and then exiting a low power state will outweigh any potential power saving gains for all but the lightest power saving modes.
Figure 1 demonstrates a typical execution pattern when regular tick interrupts are used. In this type of diagram time moves from left to right, and the horizontal colored lines represent the entity that is executing at each given time. In Figure 1 the vertical dotted lines represent times at which the regular tick interrupt occurs.
Click on image to enlarge.
In the time frame depicted by Figure 1 :
- The idle task (black line) is running for the majority of the time.
- The RTOS scheduler (red line) executes for a brief time in response to each tick interrupt.
- An application created task (blue line) is shown to execute once in response to an interrupt (the application task was in the blocked state, waiting for the interrupt, performs its processing when the interrupt occurred, then returned to the blocked state).
- The RTOS scheduler executes briefly immediately before and immediately after the application task (the scheduler executes to decide which task to run next).
The FreeRTOS tickless idle mode stops (suppresses) the periodic tick interrupt when the idle task is executing, then makes a correcting adjustment to the time maintained by the RTOS when the tick interrupt is restarted. Stopping the tick interrupt allows the microcontroller to remain in a deep power saving state until either an interrupt occurs, or it is time for the RTOS kernel to transition 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. 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.
Figure 2 demonstrates the same scenario as Figure 1 , but this time shows a typical execution pattern when tick suppression is used.
Click on image to enlarge.
In Figure 2 the idle task (black line) is not periodically interrupted by the scheduler, allowing the microcontroller on which the application is executing to remain in a very deep sleep state for prolonged periods of time.The Atmel SAM4L ARM Cortex-M4 microcontroller is specifically designedfor low power applications. The SAM4L evaluation kit (SAM4L-EK) includesa board monitor that displays the current consumed by themicrocontroller as it executes applications. Figure 3 is aphotograph of the board monitor display taken when the microcontrollerwas executing a simple FreeRTOS demonstration with the optional ticksuppression feature enabled.
Click on image to enlarge.
The application spent most of its time in the special retention lowpower mode of the SAM4L. The current readings taken when in retentionmode resulted in the flat horizontal line visible along the bottom ofthe graph in the photograph. Every 500 and 500 + 20 milliseconds anapplication task briefly left the blocked state to perform a trivialpiece of processing. The current readings taken when an application taskwas executing resulted in the two small dots that appear four times onthe graph (the measurement resolution and screen resolution make thedots appear almost as one elongated dot). As four execution instancesare visible on the graph it can be seen that the graph in the photographcovers a two second period.
A full explanation of this example, along with complete and free sourcecode and project files for immediate free download, are available on FreeRTOS.org.
Richard Barry graduated with 1st Class Honours in Computing for Real Time Systems. He's been directly involved in the start up of several companies, primarily working in the industrial automation and aerospace and simulation markets. Barry is currently a director of Real Time Engineers Ltd., owners and maintainers of the FreeRTOS project (www.FreeRTOS.org ) .