What Is an RTOS and How Real Time Operating Systems Work

RTOS stands for real-time operating system. It is an operating system built to respond to events within a guaranteed, predictable time, so a task with a deadline always runs when it must. Here is how an RTOS works inside, where it is used, and how it differs from the operating system on your laptop.

What Does RTOS Stand For?

RTOS is short for Real-Time Operating System. You will also see it written as real time OS, RT operating system, or just “the kernel” in embedded code.

The key word is “real-time.” People often read it as “very fast,” but the defining quality is determinism. An RTOS guarantees that the most important work starts within a known, bounded delay every time. A general-purpose OS cannot make that guarantee.

Consider an airbag controller. It is not enough for the controller to be fast on average. It has to fire the inflator within its deadline on every single crash. A late answer is a wrong answer, even if the calculation itself was correct.

Hard, Firm and Soft Real-Time

Not every deadline matters equally. Engineers usually sort real-time requirements into three classes.

• Hard real-time: missing a deadline is a system failure. Examples include engine control, pacemakers, and motor current loops in a robot joint.
• Firm real-time: a late result is useless and gets discarded, but one miss is not a disaster. A dropped video frame in an inspection camera fits here.
• Soft real-time: late results still have some value, and quality degrades gracefully. Audio streaming and UI responsiveness are typical.

An RTOS gives you the tools to meet hard deadlines. Whether you actually meet them depends on your design, which comes up again below.

How a Real-Time Operating System Works

Most RTOS kernels are small. FreeRTOS, for example, says a typical kernel binary falls in the region of 6 KB to 12 KB. That size lets it run on microcontrollers with only tens of kilobytes of RAM.

Inside that small footprint, an RTOS provides a handful of core services.

Tasks

A task (some kernels call it a thread) is an independent function with its own stack and a priority. Each task looks like it owns the CPU. In reality, the kernel switches between them.

A task is always in one of a few states:

• Running: currently executing on the CPU.
• Ready: able to run, waiting for the CPU.
• Blocked: waiting for an event, a timeout, or data.
• Suspended: removed from scheduling until explicitly resumed.

The Scheduler

The scheduler decides which ready task runs next. In most RTOS kernels the rule is simple: the highest-priority ready task always runs. If a higher-priority task becomes ready, it preempts the current one immediately.

That simplicity is the point. You can reason about which task will run at any moment, and that makes timing analysis possible.

Context Switching

When the scheduler swaps tasks, it performs a context switch. It saves the CPU registers and stack pointer of the outgoing task and restores those of the incoming one. On Arm Cortex-M chips, kernels typically do this inside the PendSV exception, which runs at the lowest interrupt priority so it never delays real interrupts.

Context switching costs time. A good RTOS keeps that cost small and, more importantly, constant.

Interrupt Handling

Hardware interrupts are how the outside world reaches your software. A timer expires, a UART byte arrives, an encoder pulse ticks. The RTOS makes sure an interrupt service routine (ISR) can wake a waiting task and trigger a switch to it as soon as the ISR exits.

The time from a hardware event to the first instruction of the task that handles it is called interrupt latency plus scheduling latency. Keeping that number low and bounded is the main job of the kernel.

Inter-Task Communication

Tasks need to share data without corrupting it. An RTOS typically supports:

• Queues for passing data by copy between tasks or from ISRs.
• Semaphores for signalling events and counting resources.
• Mutexes for protecting shared resources, usually with priority inheritance.
• Event flags or groups for waiting on combinations of conditions.
• Software timers for running callbacks at set times.

Memory Management

Embedded systems usually avoid unpredictable memory allocation. General-purpose malloc() can take a variable amount of time and fragment memory over weeks of uptime. That is why embedded code avoids the C heap in timing-critical paths.

RTOS kernels offer alternatives. FreeRTOS ships several heap schemes (heap_1.c through heap_5.c) and supports fully static allocation. Many kernels also provide fixed-size memory pools that allocate in constant time.

A Minimal RTOS Example in C

Here is a sketch of a 1 kHz control loop in FreeRTOS. An ISR pushes IMU samples into a queue, and a high-priority task consumes them on a fixed period.

\\#include "FreeRTOS.h"
\\#include "task.h"
\\#include "queue.h"

static QueueHandle_t imuQueue;

/* Runs when the IMU signals new data */
void IMU_IRQHandler(void)
{
    BaseType_t xWoken = pdFALSE;
    imu_sample_t s = imu_read_fifo();
    xQueueSendFromISR(imuQueue, &s, &xWoken);
    portYIELD_FROM_ISR(xWoken);   /* switch now if a higher-priority task woke */
}

static void vControlTask(void *pvParameters)
{
    TickType_t xLastWake = xTaskGetTickCount();
    const TickType_t xPeriod = pdMS_TO_TICKS(1);  /* needs configTICK_RATE_HZ = 1000 */
    imu_sample_t sample;

    for (;;) {
        while (xQueueReceive(imuQueue, &sample, 0) == pdPASS) {
            update_motor_commands(&sample);
        }
        xTaskDelayUntil(&xLastWake, xPeriod);  /* fixed period, no drift */
    }
}

int main(void)
{
    hardware_init();
    imuQueue = xQueueCreate(8, sizeof(imu_sample_t));
    xTaskCreate(vControlTask, "ctrl", 512, NULL, configMAX_PRIORITIES - 1, NULL);
    vTaskStartScheduler();   /* never returns if the scheduler starts */
    for (;;) {}
}

Notice xTaskDelayUntil() instead of a plain delay. It wakes the task relative to the last wake time, so the loop period stays fixed even if one iteration runs long.

RTOS Scheduling Algorithms

Scheduling is where real-time theory meets your code. These are the approaches you will meet most often.

Fixed-Priority Preemptive Scheduling

This is the default in FreeRTOS, Zephyr, VxWorks and most commercial kernels. You assign each task a priority, and the highest ready task runs. Tasks at equal priority usually share the CPU through round-robin time slicing.

Rate Monotonic Scheduling (RMS)

RMS is a rule for choosing priorities: the task with the shortest period gets the highest priority. Liu and Layland proved in 1973 that a set of n periodic tasks is always schedulable under RMS if total CPU utilisation stays below n(2^(1/n) − 1). As n grows, that bound approaches about 69%.

The bound is conservative. Many real task sets run fine above it, but you then need a more detailed response-time analysis to prove it.

Earliest Deadline First (EDF)

EDF picks whichever task has the nearest deadline. On a single core it can schedule task sets up to 100% utilisation. It is harder to implement and behaves badly under overload, which is why fixed priorities still dominate production firmware.

Cooperative Scheduling

In cooperative mode, a task runs until it voluntarily yields. It is simple and avoids many race conditions. The downside is that one misbehaving task can starve everything else.

Priority Inversion: The Mars Pathfinder Lesson

Priority inversion happens when a high-priority task waits on a mutex held by a low-priority task, and a medium-priority task keeps preempting the low one. The high-priority task ends up blocked behind work that matters less.

The best-known case hit NASA’s Mars Pathfinder in 1997. The lander, running VxWorks, kept resetting itself on Mars. Engineers traced it to priority inversion on a shared mutex. They fixed it by uploading a change that enabled priority inheritance on that mutex.

Priority inheritance temporarily raises the low-priority holder to the waiter’s priority so it can finish and release the lock. The priority ceiling protocol goes further by raising the holder to a preset ceiling as soon as it takes the lock.

RTOS vs General-Purpose OS

Windows, macOS and standard Linux are general-purpose operating systems (GPOS). They are tuned for throughput and fairness across many users and applications. An RTOS is tuned for worst-case timing.

Feature	RTOS	General-purpose OS
Main goal	Predictable deadlines	Average throughput, fairness
Scheduling	Strict priority, preemptive	Fairness-based, dynamic priorities
Latency	Bounded worst case	Low average, unbounded worst case
Footprint	Kilobytes	Hundreds of MB to GB
Memory	Static or pooled, often no MMU	Virtual memory, paging
Hardware	Microcontrollers, DSPs, some CPUs	Application processors
Typical boot	Milliseconds	Seconds

The two are increasingly converging. The PREEMPT_RT patches, which make most of the Linux kernel preemptible, were merged into mainline Linux in version 6.12 in late 2024. Real-time Linux gets you close to firm real-time on capable hardware, but it is still a large, complex system, and most teams keep their hardest loops on a microcontroller.

RTOS vs Bare Metal

Many small projects run “bare metal” with a super-loop: one infinite while(1) that polls everything in turn. It works well until you have several jobs with different timing needs.

You should reach for an RTOS when:

• You have more than two or three activities with different periods.
• One slow job (a flash write, a network stack) would otherwise delay a fast one.
• You need middleware such as TCP/IP, Bluetooth or USB stacks that expect threads.
• The code base is growing and you want modular tasks that teams can own separately.

Bare metal remains the right call for tiny, single-purpose devices where every byte and microamp counts.

RTOS Kernel Architectures

Kernels differ in how much they put inside the privileged core.

• Microkernel: only scheduling, IPC and basic memory protection run in kernel mode. Drivers and file systems run as separate processes. QNX Neutrino is the classic example, and its fault isolation is a big reason it shows up in cars and medical devices.
• Monolithic or single-image kernel: the kernel and application are compiled into one binary and share an address space. FreeRTOS and most microcontroller RTOSes work this way, which keeps them tiny and fast.
• Modular kernels: Zephyr sits in between, with a configurable kernel where you switch features in and out at build time through Kconfig.

Popular Real-Time Operating Systems

RTOS	Steward	License	Where you see it
FreeRTOS	Amazon Web Services	MIT	Microcontrollers, ESP32, IoT devices
Zephyr	Linux Foundation	Apache 2.0	IoT, wearables, Bluetooth devices
Eclipse ThreadX	Eclipse Foundation	MIT	Consumer electronics, MCUs
Apache NuttX	Apache Software Foundation	Apache 2.0	PX4 drone flight controllers
VxWorks	Wind River	Commercial	Aerospace, defence, industrial
QNX	BlackBerry	Commercial	Automotive, medical, robotics

ThreadX started life as a commercial product, was acquired by Microsoft as Azure RTOS, and was then handed to the Eclipse Foundation as open source. FreeRTOS came under AWS stewardship in 2017 and switched to the MIT license at that point.

Where RTOSes Are Used

Real-time operating systems sit inside far more devices than desktop operating systems do. Common applications include:

• Automotive: engine control, braking, battery management, airbag modules.
• Industrial automation: PLCs, servo drives, motion controllers for cartesian systems and gantries.
• Medical devices: infusion pumps, ventilators, patient monitors.
• Aerospace: flight computers, satellites, planetary rovers.
• Consumer and IoT: smart sensors, wearables, Wi-Fi and Bluetooth modules.

RTOS in Robotics

Robots are a good case study because they mix hard and soft timing in one machine. Every joint in a modern dog robot runs a current and position loop at kilohertz rates, often on its own microcontroller. A missed cycle there shows up as vibration or a fall.

Higher up, perception and planning run on Linux, where a few milliseconds of jitter are tolerable. The bridge between the two layers is often micro-ROS, which brings ROS 2 concepts down to microcontrollers running FreeRTOS, Zephyr or NuttX. Flight stacks follow the same split: the autopilot on a micro air vehicle or larger drone running PX4 typically sits on NuttX.

RTOS for IoT

IoT devices push RTOS design toward low power. Instead of waking every millisecond for a timer tick, a tickless idle mode lets the kernel sleep the CPU until the next scheduled event. FreeRTOS enables this with configUSE_TICKLESS_IDLE, and Zephyr supports tickless operation as well. On a battery sensor, that can be the difference between months and years of life.

Common RTOS Design Patterns

A few patterns appear in almost every well-built RTOS application.

1. Deferred interrupt handling. Keep the ISR tiny. Grab the data, signal a task, and return. Do the heavy processing in task context.
2. Producer and consumer queues. One task produces data, another consumes it through a queue. No shared globals, no races.
3. Gatekeeper task. One task owns a peripheral, such as a UART or SPI bus. Everyone else sends it requests through a queue.
4. Watchdog supervision. A monitor task checks that each critical task checks in on schedule, and only then feeds the hardware watchdog.

RTOS Performance Optimisation

Once your system works, measure it before tuning. Tools like SEGGER SystemView and Percepio Tracealyzer record every context switch and ISR so you can see where time actually goes.

For stack sizing in FreeRTOS, uxTaskGetStackHighWaterMark() tells you how close each task came to overflowing. Leave margin, then reclaim the rest for data.

Teams building complex robots increasingly test this timing behaviour in simulation first. Digital twins in robotics help, but they rarely model interrupt latency accurately, so final verification still happens on real hardware.

FAQ

What is the RTOS meaning in simple terms?

An RTOS is an operating system that guarantees important tasks run on time, every time. It trades features and average speed for predictable timing.

Is Linux a real-time operating system?

Standard Linux is not. Linux with PREEMPT_RT, now part of the mainline kernel since 6.12, achieves low and fairly predictable latency. It suits firm and soft real-time work, while hard real-time loops usually stay on a dedicated RTOS or microcontroller.

Is Windows an RTOS?

No. Windows is a general-purpose OS. Third-party extensions can add real-time behaviour, but stock Windows offers no bounded latency guarantee.

Does Arduino use an RTOS?

Classic AVR Arduino boards run bare metal. The ESP32 Arduino core runs on top of FreeRTOS, so your loop() function is actually a FreeRTOS task.

Is FreeRTOS free for commercial use?

Yes. FreeRTOS is MIT licensed, so you can use it in commercial products without paying royalties or publishing your source code.

What is the difference between an RTOS and embedded Linux?

An RTOS typically runs on microcontrollers with kilobytes of memory and boots in milliseconds. Embedded Linux needs an MMU-equipped processor and megabytes of RAM, but gives you a full networking stack, file systems and a huge software ecosystem. Many products, robots included, use both.

Keep reading

Embedded SystemsHow the Heap Works in C and Why Embedded Code Avoids ItThe C heap is a region of memory that your program borrows from at runtime with malloc(), calloc()…Oct 22, 2026 · 9 min readRobotics NewsANYbotics begins ANYmal X deliveries for oil, gas and chemical sites, it saysANYbotics says its ANYmal X ex-proof legged robot has entered commercial deliveries. Customers are company claims, and no…Oct 28, 2026 · 4 min readRobotics NewsUnitree’s first post-IPO report: Q3 revenue up 70%, profit down 17.4%Unitree's first results since listing show Q3 revenue up about 70% and profit down 17.4%. What that says…Oct 28, 2026 · 3 min read