What Is a Real-Time Operating System (RTOS)?

What is an RTOS?
RTOS in Embedded Systems
What to Expect in an RTOS
RTOS Best Practices
How to Choose an Embedded RTOS
How Can PX5 RTOS Help You?

Ask Bill Anything About RTOS

ASK BILL QUESTION

The information you submit is kept private and confidential.

Bill Lamie

Bill has been in the commercial RTOS space for over 30 years - first with Accelerated Technology (acquired by Siemens) and then with Express Logic (acquired by Microsoft). Bill was the sole author of Nucleus and ThreadX. Bill’s latest creation is the PX5 RTOS!

Message Sent

Thank you for contacting!
Bill will get back to you as soon as possible.

What Is an RTOS?

A Real-Time Operating System (RTOS) is a software platform for real-time computing applications that process events and data with well-defined time constraints. Unlike general-purpose operating systems (GPOS), an RTOS must schedule processing and data sharing between applications on limited hardware resources. Typically, these applications respond to inputs within microseconds and run on small embedded devices with less than 1 MB of memory. In this section, you’ll learn more about what an RTOS is as well as RTOS types and architectures.

RTOS Definition

An RTOS manages processor resources, including processor cycles, memory, peripherals, and interrupts. Embedded developers typically use an RTOS in situations where the application’s real-time requirements or memory constraints make a desktop operating system unsuitable.

5 Characteristics of an RTOS

  • Determinism: An RTOS is deterministic if a given input always results in the same output, often by following the same control path through code.
  • Minimal footprint: The RTOS is installed and runs with a small memory footprint to operate on resource-constrained platforms.
  • Minimal latency: The RTOS responds quickly to external events, often executing tasks within fractions of a second.
  • Concurrency: The RTOS executes multiple jobs simultaneously, using schedulers to avoid resource contention.
  • Safety and security: While not essential, many RTOSes include functional safety and cybersecurity features and are pre-certified to demonstrate support for industry best practices.

RTOS Types

There are three types of RTOSes as classified by levels of responsiveness. They are used in different types of embedded systems:

  • A hard RTOS is used in systems that have strict timing requirements where tasks must be completed within a guaranteed time frame to ensure proper functioning. Examples include automotive cruise control and railway signaling systems.
  • A firm RTOS is used in systems with a combination of tasks with deadlines that must be met and those that can tolerate occasional misses. Examples include robotic assembly lines and telecommunications networks.
  • A soft RTOS is used in systems that have flexibility in meeting task deadlines, such as in-flight entertainment and voice chat apps.

RTOS Architectures

RTOS architectures tend to fall into two categories: monolithic kernel and microkernel. A monolithic kernel RTOS houses all OS components and operating processes within the same memory space, which speeds up operations. A microkernel RTOS houses core functions separately from application-specific functions, which fosters modularity, fault tolerance, and security.

RTOS

RTOS in Embedded Systems

An embedded RTOS is the underlying software mechanism by which embedded applications run, interoperate with each other, and communicate with the outside world. In this section, you’ll learn about popular RTOSes that embedded software developers use and the embedded hardware platforms they run on.

Most Popular RTOSes

There are many choices between popular open-source and commercial RTOS suppliers:

  • Embedded Linux is a specialized version of the Linux operating system designed to run on embedded systems. While not an RTOS, this is an important and popular general-purpose GPOS in the embedded space.
  • FreeRTOS, under stewardship of Amazon, is a minimalist open-source RTOS capable of running on a wide range of platforms and processor architectures.
  • PX5 RTOS is an ultrasmall RTOS with sub-microsecond task switching and security features. PX5 RTOS is designed to run safety-critical applications and is pre-certified to facilitate compliance with functional safety standards.
  • SAFERTOS, developed by WHIS, is designed to run safety-critical applications and is pre-certified to facilitate compliance with functional safety standards.
  • ThreadX, managed by the Eclipse Foundation, is a vendor-neutral, open-source, safety-certified RTOS that supports a variety of processor architectures.
  • VxWorks, created by Wind River Systems, is a commercial RTOS used in aerospace, defense, and medical systems worldwide.
  • Zephyr, hosted by the Linux Foundation, is an open source project designed to foster an open and collaborative environment in which to deliver an RTOS.
RTOS

What to Expect in an RTOS

An RTOS uses various mechanisms to manage tasks, events, and memory to ensure time constraints are met in embedded systems. In this section, you’ll learn about RTOS features to consider when building your embedded applications, such as determinism, spatial and temporal separation, scheduling, memory management, and interprocess communications.

Deterministic RTOS

An RTOS that guarantees a task runs within a specified amount of time is called deterministic. Depending on the RTOS, determinism may be guaranteed even with unexpected inputs. PX5 RTOS is an example of a deterministic RTOS with submicrosecond context switching and API calls.

Spatial vs. Temporal Separation

Spatial separation, or spatial isolation, refers to tasks running in their own private memory space. Temporal separation ensures tasks run independently in their own time. These techniques protect memory and other resources by preventing two or more tasks from accessing the same memory space simultaneously.

RTOS Scheduling

An RTOS employs a scheduling algorithm to determine the order in which tasks are run on processing units, which ensures they meet their time constraints. The basic unit of concurrency in a real-time system is a thread, and RTOS schedulers use three parameters to schedule threads:

  • Priority. Threads are assigned a priority level, and the scheduler ensures that threads with higher priority preempt tasks at lower priority when necessary. This allows critical tasks, such as a car’s throttle control, to run without being delayed by less important tasks, such as data logging.
  • Deadline. There are two types of deadlines. An absolute deadline is the exact time by which a job must be completed. A relative deadline is the maximum allowable completion time after a given input time.
  • State. A thread is either ready (available for execution on the processing resource), running (executing), or blocked (waiting for an event, such as network data).

Preemptive RTOS and Cooperative RTOS
Preemptive and cooperative multitasking are two methods an RTOS uses to execute multiple tasks or processes simultaneously. A preemptive RTOS allows the execution of the currently running task to stop while the RTOS allocates the CPU to another process. In cooperative multitasking, only the task itself can yield control to another task, such as when it has completed its job or is blocked.

RTOS Memory Management

An RTOS divides physical memory into different sections, such as stack and heap. The stack stores a function's call information and its local variables, which requires careful management to avoid out-of-bounds memory errors. The heap allocates dynamic memory for global information and data sharing between parts of an application.

To manage memory effectively, an RTOS uses techniques, such as first-fit and best-fit, to allocate segments without overwriting other segments.

Interprocess Communication (IPC)

Interprocess communication is the mechanism by which an RTOS allows processes to synchronize and communicate with each other. Two common examples of IPC are passing messages between processes and sharing memory between processes.

Three common communication types that RTOS are:

  • RTOS queues: a first-in, first-out (FIFO) buffer in memory that supports the passing of messages between tasks.
  • RTOS semaphores: signals between tasks that do not contain data and are used to trigger an action by the receiving task.
  • RTOS mutexes: flags used to protect critical sections of code by allowing only one thread to access it at a time.
RTOS

RTOS Best Practices

When writing applications on an RTOS, there are additional considerations. Here, you’ll learn RTOS development best practices, such as POSIX compliance, security, and functional safety certification.

POSIX RTOS Compliance

An RTOS supporting the POSIX threads (pthreads) API reduces developer training and effort, as POSIX is a well-known industry standard. Using the pthreads API allows embedded developers to port code to other POSIX-compliant platforms, such as embedded Linux, which helps to protect your investment in software.

Here are examples of standards-based API calls and proprietary API calls used by different RTOSes to create a semaphore:

Standards-based IEEE POSIX API used to create a semaphore (including PX5 RTOS)

int sem_init(sem_t* semaphore_handle, int pshared, unsigned int value);

RTOSes that use proprietary APIs to create a semaphore

ThreadX RTOS API
UINT tx_semaphore_create(TX_SEMAPHORE* semaphore_handle, CHAR* name, ULONG initial_count);
FreeRTOS API
SemaphoreHandle_t xSemaphoreCreateCounting(UBaseType_t uxMaxCount, UBaseType_t unInitialCount);
Zephyr RTOS API
int k_sem_init(struct k_sem* sem, unsigned int initial_count, unsigned int limit);

By contrast, any application using a POSIX-compliant RTOS call can be ported to another compliant RTOS with minimal effort.

RTOS Security

The key aspects of RTOS security are maintaining spatial separation between tasks, so a compromised component does not impact other components in an embedded system, and protecting the system from external threats.

An advanced RTOS like PX5 RTOS provides security-specific enhancements for memory corruption detection and mitigation. Known as pointer data verification (PDV), this feature checks function pointers, system objects, global data, and memory pools for corruption to prevent remote execution attacks.

Safety-Certified RTOS

A safety-certified RTOS or pre-certified RTOS complies with one or more functional safety standards, such as IEC 61508 or ISO 26262. For developers of safety-critical and non-safety-critical devices, a safety-certified RTOS offers a stable, reliable foundation built to industry best practices, which supports greater product reliability, security, and quality as well as faster time to market.

As an example, PX5 RTOS is pre-certified to the highest levels of the IEC 61508, IEC 62304, ISO 26262 and EN 50128 functional safety standards. Embedded software developers who use PX5 RTOS can re-use its certification artifacts to save time and money during application certification.

RTOS

How to Choose the Best Embedded RTOS

Your choice of RTOS affects embedded system performance, development time, regulatory compliance, and total cost. The main selection criteria for an RTOS are usually the overhead it imposes on the processor and response time of RTOS functions, such as:

  • Interrupt latency: delay between an interrupt coming from an external event and the response to that interrupt.
  • Context switch time: time it takes to switch from one task to another, generally the most time-consuming set of operations in a real-time system.
  • Memory footprint: amount of physical memory (ROM and RAM) required by the RTOS to store kernel code, runtime libraries, and middleware as well as application processing overhead.

On the best RTOSes, context-switching and API call overhead is less than a few microseconds. In situations where greater responsiveness is required, an ultrasmall high-performance RTOS, such as PX5 RTOS, is used to minimize overhead.

RTOS Selection Criteria

Other RTOS selection considerations are:

  • Features
  • Platform support
  • Ecosystem support
  • POSIX compliance
  • Security
  • Functional safety certification
  • Licensing
  • Documentation
  • Support

Bare Metal vs. Open Source vs. Commercial RTOS

When deciding whether to use a bare metal, open source RTOS, or commercial RTOS, there are several considerations:

  • Bare metal systems have applications running directly on hardware with no intermediate software layers. These systems are easier to optimize for performance but require more effort to add features and secure as there is little to no ecosystem support.
  • Open source RTOSes are freely available and come with community-driven features and support. They often lack enterprise-level support, unless it is purchased separately.
  • Commercial RTOSes are optimized for a range of use cases and are backed by professional engineering and support teams to roll out features and solve issues.
RTOS

How Can PX5 RTOS Help You?

PX5 RTOS is one of the smallest, highest performance RTOSes ever developed. Ideal for resource-constrained devices, PX5 RTOS delivers sub-microsecond context switching and API calls, and it requires less than 1 KB of flash memory to run. Designed as a native implementation of the POSIX pthreads API standard, PX5 RTOS enables code portability with embedded Linux and other POSIX RTOSes.

Secure and Safety-Certified RTOS

PX5 RTOS helps embedded developers meet system requirements for cybersecurity and functional safety in these ways:

  • PX5 tests its entire RTOS code base with complete C statement and branch decision coverage for every release.
  • Pointer data verification (PDV) technology provides added security through run-time function pointer, system object, buffer and stack verification.
  • SGS-TÜV Saar-the leading accredited, independent company for testing, auditing, verifying, and certifying embedded software for safety-related systems-certifies PX5 RTOS as meeting the functional safety standards IEC 61508 SIL 4 (electronic), IEC 62304 Class C (medical), ISO 26262 ASIL D (automotive) and EN 50128 SW-SIL 4 (rail).
RTOS
Mouse over for component details
pthread threads pthread mutexes pthread condition variables pthread semaphores pthread signals POSIX message queues & timers
PX5 RTOS pthread+ extensions
PX5 RTOS C Implementation (px5.c) PX5 RTOS Binding Layer (px5_binding.s)

Figure 1: Components of the PX5 RTOS

PX5 RTOS Benefits and Highlights

Rich determinism makes PX5 RTOS ideal for the most demanding real-time embedded applications. Features include:

  • Advanced 5th generation RTOS by the author of ThreadX and Nucleus
  • Complete source code, written in ANSI C, including the RTOS binding layer source
  • Royalty-free licensing
  • Asymmetric multiprocessing (AMP) and symmetric multiprocessing (SMP) support
  • Works with ARM Cortex-M, Cortex-R, Cortex-A, and RISC-V architecture processors
  • Works with boards from AMD, GigaDevice, NXP Semiconductors, Renesas, SiFive, STMicroelectronics and Texas Instruments
  • Expert tech support, rich documentation, and helpful videos to simplify use

To learn more about PX5 RTOS, explore our product page.

 
RTOS markets

The PX5 RTOS enables you to deliver better quality IoT devices in record time for the most demanding applications.

  • System-on-Chip (SoC)
  • Industrial
  • Medical Devices
  • Consumer Electronics
  • Automotive
  • Office Automation
  • Networking
  • Military/Aerospace
Discover PX5 RTOS

Your Feedback

Matters!

Please answer 5 quick questions to help us better meet your needs!

Begin Survey

What do you like about the PX5 RTOS?

Continue

What do you dislike about the PX5 RTOS?

Continue

What would you like to see the PX5 RTOS?

Continue

What do you like about our website?

Continue

How can we improve our website?

Send Survey

Survey Completed

Thank you

We sincerely appreciate your valuable input and the time you’ve taken to complete a survey.

Close