A New RTOS Approach to Achieve Sub-Millisecond Timing Resolution

Have you ever worked with a real-time operating system (RTOS) only to discover it didn’t have the resolution to schedule or delay tasks below a millisecond? You probably had to write a bunch of your application code outside the context of the RTOS. While this is “fine”, it should have made you suspicious whether the application met its deadlines, was maintainable and scalable. Shouldn’t an RTOS be able to manage the timing of the entire application, whether that timing is a second or a microsecond?

Balancing temporal precision and energy efficiency can be a constant struggle for developers and managers in the embedded systems domain. The demand for precise timing control grows as applications evolve, whether in automotive, IoT, medical devices, or industrial automation. While effective in managing real-time tasks, traditional RTOS solutions often fall short in two critical areas.

Traditional RTOS Shortfalls

First, they have precision limitations. Tick-based systems cannot offer timing granularity beyond configured tick intervals (e.g., 1 millisecond). This constraint impacts the ability to perform ultra-fine timing operations, such as precise sensor readings or high-resolution control in advanced robotics. In fact, if you aren’t careful, you can even inject jitter into your task timing, disrupting the system’s real-time performance!

Second, tick-based RTOSes are energy inefficient! The periodic system tick interrupts keep the CPU active even when no tasks are scheduled, leading to wasted energy—an issue especially critical in battery-operated and low-power devices. While some RTOSes have tried to overcome this limitation by introducing tickless power-saving modes, these solutions are more band-aids than full features.

These limitations force developers into inefficient workarounds, like polling hardware timers or using target-specific techniques to achieve finer resolution and lower power consumption. Such approaches complicate the development process and make software less portable and maintainable.

In this post, we will explore a new mechanism for precisely scheduling tasks below a millisecond. This mechanism can improve your application’s real-time performance while increasing energy efficiency. The benefits come from a new RTOS implementation that leverages cycle-resolution timing.

From Tick-Based to Cycle-Based Scheduling

Traditional RTOSes use periodic system ticks to track time and schedule tasks. For example, most RTOSes, such as FreeRTOS, Zephyr, and embOS-Base, are configured with a 1-millisecond tick interval by default. This interval relies on a timer generating an interrupt every millisecond. All time-based operations—task delays, timeouts, and software timers—are then aligned with these ticks. If we use a tool like SEGGER SystemView to record and analyze the application’s run-time behavior, we’d see something like Figure 1 below.

Figure 1: Traditional RTOS with a periodic tick to track system time.

As you can see, every millisecond the system tick interrupts the application! If the system was sleeping and had no other useful work to do, it would have woken up to increment a counter and go back to sleep!

A tick-based design inherently limits timing precision and introduces latency, as tasks cannot be scheduled with finer granularity than the configured tick interval. This is an issue that I’ve encountered in numerous applications which forces you to think outside the RTOS.

Cycle-based scheduling eliminates this constraint by replacing the periodic tick interrupt with a single-shot hardware timer. Instead of waking the CPU every millisecond, the timer only generates an interrupt when needed, allowing events to be scheduled precisely down to microseconds or CPU cycles. This approach enhances precision and reduces the CPU’s activity, conserving energy.

Let’s look at an example. Consider a task delay that needs to last precisely 4.7 milliseconds. In a tick-based RTOS with a 1-millisecond tick interval, the delay would either end early (at 4 ms) or extend longer (to 5 ms), depending on the tick timing. The exact 4.7-millisecond delay is achievable with cycle-based scheduling, as it no longer depends on the tick interval.

embOS-Ultra: A Technical Solution to Precision and Efficiency

If you survey the RTOS market today, you’ll find that SEGGER’s embOS-Ultra is the only RTOS available that supports cycle-based scheduling. Therefore, we will look closely at how embOS-Ultra addresses the challenges of precision and efficiency by introducing cycle-resolution timing and how this innovative approach can improve applications.

Let’s break down how embOS-Ultra technically solves the issues of precision and efficiency without adding unnecessary complexity.

Energy Efficiency Through Single-Shot Timers

By removing the periodic tick, embOS-Ultra significantly lowers CPU load. Traditional RTOS systems wake the CPU at every tick, even if no work is pending. This behavior increases power consumption, as the CPU must save its state, handle the interrupt, and restore its state, consuming energy through unnecessary CPU cycles.

embOS-Ultra’s single-shot timer only wakes the CPU when a specific event occurs, keeping the system in a low-power state for extended periods. This feature is particularly advantageous for low-power and battery-operated applications, such as wearable devices or remote IoT sensors, where every bit of energy saved extends operational time. However, even devices that are connected to constant power can benefit by decreasing their overall energy profile and decreasing demand on the power grid.

In many microcontroller architectures, timers can be configured in various modes. embOS-Ultra leverages a mode where the timer counts down to zero or up to a specified value, triggering an interrupt exactly when needed. This flexibility lets developers precisely control timing events without relying on periodic ticks. As you can imagine, there can be benefits to allowing a timer free-count for scheduling versus having it count to zero and then having to reset it.

Managing Long-term System Stability

You might think that while a single timer used to provide high-resolution, sub-millisecond scheduling sounds great, losing your system tick will break your application. The good news is that it won’t! embOS-Ultra uses two hardware timers. One timer is used for long-term stability and runs continuously without generating interrupts. The second timer, the single-shot timer we discussed in the previous section, is used for task scheduling.

This means that no complex algorithms are running in the background trying to determine how many milliseconds have elapsed since system start-up! Let’s be honest: most of us leverage that system tick to provide timestamps, calculate filters, and perform other routine activities! If it were removed from the RTOS, our lives would become much more difficult.

Adding a second timer to the mix might seem to add complexity and energy inefficiency to the system, but it’s not. Most 32-bit microcontrollers today have more timers than developers know what to do with and operate using very little current compared to the CPU. The trade-off of using a second-timer still ensures that we minimize energy consumption while also maintaining long-term stability in our systems’ real-time performance.

Cycle-based Scheduling in Action

Now that you understand how cycle-based scheduling works, let’s examine an example. SEGGER’s website has a live comparison example that can simulate the behavior of tick-based and cycle-based scheduling. I recommend trying it out to get some hands-on experience with it.

The live comparison allows you to see how many ticks occur each second through print statements. The test application has two tasks: a 201-millisecond task and a 50-millisecond task. For the tick-based scheduler, you’ll get 1000 ticks per second. If you simulate the same application with cycle-based scheduling, you only get 24 – 25 ticks per second.

Unfortunately, with a simulation, you can’t use SystemView to record and analyze the application behavior. However, I didn’t allow that to stop me. I used the live comparison example and a development board to analyze what the cycle-based scheduling looked like. Figure 2 below shows the results:

Figure 2: Cycle-based scheduling for the same application shown in Figure 1.

If you look at the timing difference in Figure 2 at the bottom of the analysis window, you’ll see that the system tick does not tick at regular intervals. You can see that there is a tick only when necessary! You can see along the bottom of Figure 2 that there is a 49.9-millisecond spacing between ticks, and then a 16.9-millisecond delay, and so forth. This is the cycle-based timing at work! Instead of a 1,000 ticks per second, the cycle-based scheduling application only has 24 – 25 ticks per second, depending on how the task deadlines lie.

Adopting Cycle-based Scheduling while Maintaining Backward Compatibility

The risk and complexity associated with migrating to a new RTOS can be a significant concern for developers and managers. embOS-Ultra addresses this by maintaining compatibility with existing APIs and behavior while offering extended functionality. There are two primary concerns that you need to keep in mind.

First, legacy support for applications using embOS-Base or other tick-based RTOS APIs continues to function as expected in embOS-Ultra. The traditional millisecond-based timing is preserved, ensuring that legacy codebases remain intact. That means you don’t need to be concerned with the changes under the hood. If you are using embOS-Base, the APIs are directly compatible. If you use another RTOS, you’ll likely have a day or so to update your RTOS calls to the embOS-Ultra ones.

Second, for developers needing higher precision, embOS-Ultra introduces an extended API, such as OS_TASK_Delay_us() for microsecond delays or OS_TASK_Delay_Cycles() for cycle-based scheduling. These new functions coexist with traditional API calls, allowing developers to gradually adopt advanced features without modifying the entire codebase.

Let’s look at an example. Let’s say we want to print “Hello World!” to the terminal every 1,000,000 cycles. I might create an RTOS task named Hello with the following syntax:

void Hello(void)

{

    printf("Hello World!\n");

    printf("The next output will occur in 1,000,000 Cycles.\n");

    OS_TASK_Delay_Cycles(1000000);

    printf("Delay is over.\n");

}

OS_TASK_Delay_Cycles specifies the minimum time interval in cycles during which the task is suspended. So, if the system cycle count is 1,000,000 when OS_TASK_Delay_Cycles is called, the 1,000,000-cycle delay will expire at the system cycle count of 2,000,000.

It’s important to note that as a developer, you have control over the time interval that a single cycle represents. It can be a single clock of your CPU or a more extended period, depending on how you configure clock dividers that feed the timer you use. The good news is that SEGGER provides numerous ports for various microcontrollers, so you won’t have to write these yourself; you only know how to adjust them through the APIs if the defaults don’t meet your needs.

This dual-approach design means engineers do not have to choose between legacy support and high precision—they can use both within the same application. Whether migrating from embOS-Base or another tick-based system like CMSIS-RTOS, developers can leverage embOS-Ultra with minimal effort, as the necessary application changes are minimal and straightforward.

Next Steps for Empowering Precision and Efficiency in Embedded Development

Cycle-based scheduling represents a technological advancement that addresses the core challenges developers and managers face in today’s embedded systems—achieving microsecond precision while maximizing energy efficiency. By eliminating the traditional system tick and offering a flexible, cycle-based approach, embOS-Ultra delivers a solution that is precise, power-efficient, and compatible with existing RTOS setups.

Cycle-based scheduling provides a practical and advanced alternative for embedded professionals looking to elevate their systems’ performance and energy profile without the risk of complex migrations. There are several steps you can take to learn more about cycle-based scheduling.

First, check out the embOS-Ultra RTOS User Guide & Reference Manual. It contains many great examples that describe how high-precision and cycle-based scheduling work.

Next, SEGGER has an example simulation project that you can use to test the differences between embOS-Base and embOS-Ultra. You can download it here and give it a spin or even try it out on your development board.

Finally, if you see the benefit of more precise timing and energy savings in your application, adopt cycle-based timing for your embedded system.