Most embedded systems now use some form of operating system, particularly if they are based on a modern 32-bit core like the Arm Cortex-M family. Support for embedded real-time operating systems is strong, thanks to the benefits they bring. But real-time comes in many shapes, so what can engineers do if they need to maintain hard real-time execution? One approach is to make full use of the hardware features offered by the processing platform.

A low-level operating system provides an abstraction layer between the application code and the device’s hardware features. This makes it easier for higher-level code, such as middleware, to access the available hardware features.

A real-time operating system, or RTOS, provides a way of managing these features. The real-time part provides some guarantee that things happen just when you want them to. This can create conditions where the software and hardware battle for control. The way around this is to turn off features that could disrupt the flow, but this too has problems. If certain features, like interrupts, are turned off (masked) even for very short periods, there is a chance that an event will be missed.

This basically describes the huge challenges involved and the enormous skills required when developing real-time systems. The RTOS was designed to mitigate these issues, using techniques such as ticks, semaphores and interrupt service routines (ISR). All these features are normally software based.

The concept behind the proprietary HW-RTOS, or hardware RTOS, is to implement these features in hardware and access them through APIs. What this brings is low interrupt latency with low jitter and very short interrupt disable periods.