FreeRTOS's tick suppression saves power
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.