Have you found it impossible to reduce task scheduling or delay precision below milliseconds when using a Real-Time Operating System (RTOS)? You might have had to write a lot of application code outside of the RTOS. While this approach works, it raises concerns about whether the application meets its deadlines and whether it is maintainable and scalable. Shouldn’t the RTOS be able to manage the timing of the entire application, regardless of whether that timing is a second or a microsecond?
For developers and managers in the embedded systems field, balancing timing precision and energy efficiency can be a continuous struggle. As applications evolve, the demand for precise timing control is growing in sectors such as automotive, IoT, medical devices, and industrial automation. While traditional RTOS solutions are effective in managing real-time tasks, they often fall short in these two critical areas.
1. Limitations of Traditional RTOS
First, traditional RTOS has precision limitations. Tick-based systems cannot provide time granularity beyond the tick interval (e.g., 1 millisecond). This limitation affects the ability to perform ultra-fine timing operations, such as precise sensor readings or high-resolution control of advanced robotics. In fact, if not careful, you might even inject jitter into task timing, compromising the system’s real-time performance!
Secondly, tick-based RTOS has low energy efficiency! Even without task scheduling, periodic system tick interrupts keep the CPU active, leading to energy waste, which is particularly severe in battery-powered and low-power devices. While some RTOS attempt to overcome this flaw by introducing tickless power-saving modes, these solutions are more of a band-aid than a complete solution.
These limitations force developers to adopt inefficient solutions, such as polling hardware timers or using target-specific techniques to achieve higher resolution and lower power consumption, complicating the development process and reducing the portability and maintainability of the software.
In this article, we will explore a new mechanism for accurately scheduling tasks below one millisecond, which can enhance the real-time performance of applications while improving energy efficiency, benefiting from a new RTOS implementation that utilizes periodic precision timing.
2. From Tick-Based Scheduling to Periodic Scheduling
Traditional RTOS uses periodic system ticks to track time and schedule tasks. For example, most RTOS, such as FreeRTOS, Zephyr, and embOS-Base, default to a tick interval of 1 millisecond. This interval relies on a timer that generates an interrupt once every millisecond. All time-related operations (task delays, timeouts, and software timers) are aligned with the ticks. If we use tools like SEGGER SystemView to log and analyze the runtime behavior of applications, we would see something like what is shown in Figure 1.
Figure 1: Traditional RTOS using periodic ticks to track system time
As shown, the system interrupts the application every millisecond, and if the system is in sleep mode with no other work to do, it will be woken up to increment the count and return to sleep!
The tick-based design limits timing precision and introduces delays, as tasks cannot be scheduled with granularity finer than the tick interval, which is a problem I encounter in many applications that force you to think outside of RTOS implementations.
Periodic scheduling eliminates this constraint by replacing periodic tick interrupts with a single-shot hardware timer. The timer generates interrupts only when needed, rather than waking the CPU every millisecond, allowing event scheduling to be precise to microseconds or CPU cycles. This approach improves precision, reduces CPU activity, and saves energy.
Let’s look at an example. Consider a task delay that needs to last 4.7 milliseconds. In an RTOS with a 1-millisecond tick interval, the delay will either end early (4 milliseconds) or extend (5 milliseconds), depending on the tick timing. Using periodic scheduling allows for an accurate 4.7-millisecond delay because it no longer relies on the tick interval.
3. embOS-Ultra: A Technical Solution for High Precision and High Efficiency
If you survey the current RTOS market, you will find that SEGGER’s embOS-Ultra is the only RTOS that supports periodic scheduling. Therefore, we will focus on how embOS-Ultra addresses the challenges of precision and efficiency by introducing periodic resolution timing and how this innovative approach improves applications.
Let’s analyze how embOS-Ultra solves precision and efficiency issues without adding unnecessary complexity.
Improving Energy Efficiency with Single-shot Timers
By removing periodic ticks, embOS-Ultra significantly reduces CPU load. Even with no pending work, traditional RTOS wakes the CPU at every tick, increasing power consumption because the CPU must save its current state, process the interrupt, and restore its state, consuming unnecessary CPU cycles that drain energy.
The single-shot timer in embOS-Ultra wakes the CPU only when specific events occur, allowing the system to remain in a low-power state for extended periods. This feature is particularly beneficial for low-power and battery-powered applications, such as wearable devices or remote IoT sensors, where every bit of saved energy extends runtime. However, even devices connected to a constant power source can benefit from reduced overall energy consumption and a decreased demand on the power grid.
In many microcontroller architectures, timers can be configured for various modes. embOS-Ultra leverages timer counts down to zero or to a specified value to trigger interrupts when needed. This flexibility allows developers to precisely control timing events without relying on periodic ticks. As imagined, allowing the timer to count freely for scheduling is more beneficial than resetting after counting to zero.
Maintaining Long-Term Stability of the System
You might think that while using a single timer to provide high-resolution, sub-millisecond scheduling sounds great, losing the system tick would disrupt the application. The good news is that it does not; embOS-Ultra uses two hardware timers. One timer is used for long-term continuous operation without generating interrupts. The second timer, the single-shot timer we discussed in the previous section, is used for task scheduling.
This means there are no complex algorithms running in the background trying to determine how many milliseconds have elapsed since the system was started. Honestly, most of us leverage the system tick to provide timestamps, calculate filters, and perform other daily activities. If we remove it from the RTOS, our development becomes more challenging.
Adding a second timer might seem to increase system complexity and energy efficiency, but that is not the case. Nowadays, most 32-bit microcontrollers have multiple timers, and the current used by counters is minimal compared to the CPU. The trade-off of using a second timer still ensures we minimize energy consumption while maintaining the long-term stability of the system’s real-time performance.
4. Applications of Periodic Scheduling
Having understood how periodic scheduling works, let’s examine an example. SEGGER’s website provides a live comparison example (https://www.segger.com/products/rtos/embos/editions/embos-ultra/#live-comparison) that simulates tick scheduling and periodic scheduling behavior. I recommend trying it out to gain some practical experience.
The live comparison example allows you to see how many ticks are generated per second through print statements. The test application contains two tasks: a 201-millisecond task and a 50-millisecond task. The tick-based scheduler generates 1000 ticks per second. If periodic scheduling is used to simulate the same application, only 24 – 25 ticks are generated per second.
Unfortunately, for the simulation program, you cannot use SystemView to log and analyze application behavior, so I used the live comparison example running on a development board to analyze periodic scheduling. The results are shown in Figure 2:
Figure 2: Periodic scheduling implementation of the same application shown in Figure 1
If you look at the timing differences at the bottom of the analysis window in Figure 2, you will see that the system’s tick interval is not fixed. There is a tick only when necessary, and at the bottom of Figure 2, you can see intervals of 49.9 milliseconds between ticks, followed by a delay of 16.9 milliseconds, and so on. This is periodic timing! The periodic scheduling application has only 24 – 25 ticks per second, depending on the task deadlines.
5. Using Periodic Scheduling While Maintaining Backward Compatibility
The risks and complexities associated with migrating to a new RTOS may be significant concerns for developers and managers. embOS-Ultra addresses this issue by maintaining compatibility with existing APIs while providing extended functionality.
First, applications using embOS-Base or other tick RTOS APIs can continue to function as expected in embOS-Ultra. The millisecond-based timing functionality is retained in embOS-Ultra, ensuring that existing code requires no modification. If using embOS-Base, the API is directly compatible. If using other RTOS, you might spend a day or so updating the RTOS calls to embOS-Ultra.
Secondly, for developers needing higher precision, embOS-Ultra introduces extended APIs, such as OS_TASK_Delay_us() for microsecond delays or OS_TASK_Delay_Cycles() for periodic scheduling. These functions coexist with traditional API calls, allowing developers to gradually adopt advanced features without modifying the entire codebase.
Let’s look at an example. Suppose we want to send “Hello World!” to the terminal every 1,000,000 cycles; I might create an RTOS task named Hello with the following syntax:
OS_TASK_Delay_Cycles specifies the minimum time interval for the task suspension operation in cycles, so when OS_TASK_Delay_Cycles is called, if the system cycle count is 1,000,000, the delay of 1 million cycles will expire when the system cycle count reaches 2,000,000.
Note that as a developer, you can control the time interval represented by a single cycle. It can be a single CPU cycle or a longer time, depending on how you configure the clock prescaler for the timer used. The good news is that SEGGER provides numerous porting implementations for various microcontrollers, so you don’t have to write these yourself; you only need to know how to adjust through the API when the defaults do not meet your needs.
This dual-timing method means engineers do not have to choose between traditional implementations and high precision; they can use both approaches simultaneously within the same application. Whether migrating from embOS-Base or other tick-based systems (such as CMSIS-RTOS), developers can easily adopt embOS-Ultra as the necessary application changes are minimal and straightforward.
6. Next Steps
Periodic scheduling represents a technological advancement that addresses the core challenges faced by developers and managers in today’s embedded systems, achieving microsecond precision while maximizing energy efficiency. By eliminating traditional system ticks and providing a flexible, periodic approach.
Periodic scheduling offers embedded professionals seeking to enhance system performance and energy configuration without the complex risks of migration a practical and advanced alternative. You can learn more about periodic scheduling through the following steps.
First, check the embOS-Ultra RTOS manual (https://www.segger.com/downloads/embos/UM01076_embOS_Ultra.pdf), which contains many examples describing how high precision and periodic scheduling work.
Finally, after confirming the benefits of more precise timing and energy savings, you can adopt periodic timing functionality in embedded systems.
———— END ————
●Column “Embedded Tools”
●Column “Embedded Development”
●Column “Keil Tutorial”
●Selected Tutorials from the Embedded Column
Follow the public account Reply “Add Group” to join the technical exchange group according to the rules, reply “1024” to see more content.