Mastering Embedded Systems: From Bare Metal to Real-Time Operating Systems

Embedded systems sit at the heart of countless devices, from tiny sensor nodes to complex industrial controllers. Choosing the right software architecture—bare metal or a real-time operating system (RTOS)—can make or break a project in terms of reliability, development time, and maintainability. This guide provides a structured approach to mastering both paradigms, helping you decide when to stay on bare metal and when to adopt an RTOS, and how to transition smoothly.

Why the Bare-Metal vs. RTOS Decision Matters

Every embedded project begins with a fundamental question: should the firmware run directly on the hardware with a simple super-loop, or should it be built on top of an RTOS? The answer affects everything from interrupt latency and power consumption to code complexity and team productivity. Bare-metal programming gives you complete control over the CPU and peripherals, with minimal overhead—ideal for very simple tasks or extreme cost constraints. However, as the number of concurrent responsibilities grows, bare-metal code can become a tangled web of state machines and interrupt service routines (ISRs) that are hard to maintain and debug.

An RTOS introduces a scheduler that manages multiple tasks, each with its own stack and priority. This abstraction simplifies code organization and makes it easier to add features later. But it comes at a cost: additional flash and RAM usage, potential for priority inversion, and a learning curve for the team. Many industry surveys suggest that projects using an RTOS have lower defect rates in the long run, but the initial investment is higher.

When Bare Metal Wins

Bare metal is often the right choice for ultra-low-power devices that spend most of their time in sleep mode, or for systems with only one or two well-defined tasks. For example, a temperature sensor that wakes up every minute, reads a sensor, and sends data over a serial link can be implemented cleanly with a simple state machine. The absence of an RTOS saves code space and avoids the overhead of context switching.

When an RTOS Shines

As soon as you need to handle multiple asynchronous events—like a user interface, network communication, and sensor fusion—an RTOS becomes attractive. Consider a drone flight controller: it must read gyroscope data, compute control outputs, handle GPS updates, and manage telemetry, all with strict timing constraints. An RTOS lets you split these concerns into separate tasks, each with a priority that matches its urgency.

The Gray Zone

Many projects fall in between. A common mistake is to start with bare metal and then try to retrofit an RTOS when complexity grows. This often leads to a hybrid mess where some parts use the RTOS scheduler and others bypass it. A better approach is to evaluate the expected complexity early and make a deliberate choice. If you anticipate more than three concurrent responsibilities, an RTOS is usually worth the overhead.

Core Concepts: How Bare Metal and RTOS Work

To make an informed decision, you need to understand the underlying mechanisms. Bare-metal firmware typically runs a super-loop that polls peripherals and checks flags set by ISRs. The CPU is either executing code or sleeping. Interrupts preempt the main loop, but the main loop has no concept of priorities—every operation runs to completion before the next poll cycle.

An RTOS, on the other hand, provides a scheduler that decides which task to run next based on priorities and events. Tasks are independent threads of execution, each with its own stack. The scheduler is invoked by a periodic timer tick or by task blocking (e.g., waiting for a semaphore). Context switching saves and restores the CPU registers, which adds latency but enables deterministic multitasking.

Scheduling Policies

Most RTOS kernels support preemptive priority-based scheduling, where a higher-priority task preempts a lower-priority one as soon as it becomes ready. Some also offer round-robin or time-slicing for tasks of equal priority. Understanding which policy fits your application is critical. For hard real-time systems, fixed-priority preemptive scheduling is common, but it can suffer from priority inversion—a lower-priority task holding a resource needed by a higher-priority task. Priority inheritance protocols can mitigate this.

Interrupt Latency and ISR Design

Interrupt latency is the time from the hardware interrupt signal to the first instruction of the ISR. In bare-metal systems, this is minimal because there is no scheduler overhead. In an RTOS, interrupts are often handled by a small ISR that signals a task, deferring the heavy processing to the task context. This reduces the time spent with interrupts disabled but adds a context switch. The trade-off is acceptable for most systems, but for extremely fast events (e.g., microsecond-level sensor readouts), bare metal may still be necessary.

Memory Footprint Comparison

A typical RTOS kernel adds 2–12 KB of flash and 1–4 KB of RAM for the kernel structures, plus additional stack per task. For a microcontroller with 64 KB flash and 8 KB RAM, this is a significant but manageable overhead. Bare-metal firmware can be as small as a few hundred bytes. The choice often comes down to whether the extra memory is available and whether the development time saved is worth it.

A Step-by-Step Process for Transitioning from Bare Metal to RTOS

If you have decided to move from bare metal to an RTOS, follow this structured approach to avoid common pitfalls.

Step 1: Analyze Your Current Code

Identify all the concurrent activities in your bare-metal firmware. List every ISR, state machine, and polling loop. Group them by their timing requirements: which ones must run at a fixed rate, which are event-driven, and which can tolerate jitter. This analysis will become your task list.

Step 2: Map Activities to Tasks

Each independent activity becomes a task. For example, a UART receive handler might be a task that blocks on a queue, while a sensor read runs periodically. Assign priorities based on urgency: tasks that must meet deadlines get higher priorities. Be careful not to create too many tasks—each task consumes stack space and adds context-switch overhead. Aim for 4–8 tasks on a small MCU.

Step 3: Choose Synchronization Primitives

RTOS provides semaphores, mutexes, queues, and event flags. Use queues for data passing between tasks (e.g., sensor readings to a logging task). Use mutexes for shared resources, but be aware of priority inversion. For simple signaling, semaphores or event flags are lighter. Avoid using global variables protected by disabling interrupts—that defeats the purpose of an RTOS.

Step 4: Rewrite ISRs

In an RTOS, ISRs should be as short as possible. Typically, an ISR clears the interrupt flag, reads data into a buffer, and then posts a semaphore or sends a message to a queue. The actual processing happens in a task that is awakened by the ISR. This pattern reduces interrupt latency for other interrupts and keeps the system responsive.

Step 5: Test Incrementally

Start by running one or two tasks alongside your existing bare-metal code. Gradually move functionality into tasks while verifying timing and resource usage. Use a logic analyzer or oscilloscope to measure jitter and response times. Many RTOS kernels include stack overflow detection and runtime statistics—enable them during development.

Common Transition Mistakes

One frequent error is to treat the RTOS as a black box and ignore its configuration. For instance, setting the tick rate too high (e.g., 1 kHz) wastes CPU time on context switches; 100 Hz is often sufficient. Another mistake is to use blocking delays inside tasks (like vTaskDelay(100)) instead of using proper synchronization—this can cause priority inversion and missed deadlines. Finally, neglecting to set stack sizes correctly leads to mysterious crashes. Use the RTOS's built-in stack watermark feature to tune sizes.

Tools, Stacks, and Maintenance Realities

Choosing the right toolchain and RTOS kernel is as important as the architecture itself. The market offers a range of options, from commercial kernels with certified safety packages to open-source kernels with large communities.

Popular RTOS Options

FreeRTOS is a solid starting point for most projects due to its permissive license and extensive documentation. Zephyr offers a more modern codebase with built-in driver frameworks, but has a steeper learning curve. For safety-critical applications (e.g., medical devices), consider a certified RTOS like ThreadX or a commercial variant with IEC 62304 certification.

Development Environment

Most embedded developers use an IDE like STM32CubeIDE, Keil, or IAR, or a command-line toolchain with CMake and GCC. The RTOS kernel is typically distributed as source code that you compile alongside your application. Ensure your toolchain supports the target MCU's architecture (ARM Cortex-M, RISC-V, etc.).

Maintenance Considerations

An RTOS adds a dependency that must be maintained. Kernel updates may introduce breaking changes, especially if you use vendor-specific ports. Keep a copy of the RTOS source in your version control system and document the version used. Also, plan for code reviews that focus on RTOS-specific issues like task stack sizes and priority assignments. Over time, you may need to tune the system as new features are added.

Growth Mechanics: Scaling Your Embedded System

As your product evolves, the embedded software must scale without requiring a complete rewrite. This section covers strategies for handling increased complexity, team collaboration, and performance tuning.

Modular Design with RTOS

An RTOS naturally encourages modularity: each task is a self-contained unit with its own stack and synchronization points. This makes it easier to add new features without breaking existing ones. For example, adding a new sensor can be done by creating a new task that reads the sensor and sends data via a queue. The existing tasks remain unchanged.

Performance Tuning

When the system grows, you may encounter performance bottlenecks. Common tuning techniques include adjusting task priorities, reducing tick rate, and using direct-to-task notifications instead of semaphores for faster signaling. Profile the CPU load using the RTOS's idle task hook—if the idle task runs less than 30% of the time, you may be overloading the CPU. Consider moving some processing to hardware peripherals (e.g., DMA for data transfer) to offload the CPU.

Team Collaboration

In a team setting, clear documentation of task responsibilities, shared resources, and synchronization rules is essential. Use a table that lists each task, its priority, stack size, and the queues or semaphores it uses. Enforce coding standards that prohibit direct access to shared variables—always use RTOS primitives. Code reviews should check for potential deadlocks and priority inversions.

When to Re-Architect

If your system has grown to 20+ tasks and the scheduler is spending more than 10% of CPU time on context switches, it may be time to reconsider the architecture. Sometimes merging related tasks into a single task with a state machine can reduce overhead. Alternatively, consider moving to a more powerful MCU with more cores or a higher clock speed.

Risks, Pitfalls, and Mitigations

Even experienced developers encounter common pitfalls when working with RTOS. Recognizing them early can save weeks of debugging.

Priority Inversion

Priority inversion occurs when a high-priority task is blocked waiting for a resource held by a low-priority task, while a medium-priority task preempts the low-priority task. The high-priority task effectively runs at the medium task's priority. Mitigation: use a mutex with priority inheritance (most RTOS kernels support this), or design the system so that critical resources are held for a very short time.

Stack Overflow

Each task has a fixed stack size. If the stack overflows, it corrupts adjacent memory, causing erratic behavior. Mitigation: enable stack overflow detection (usually a hardware check or a software watermark). Start with generous stack sizes (e.g., 256–512 bytes per task) and then reduce based on actual usage measured with the RTOS's stack watermark API.

Deadlock

Deadlock happens when two or more tasks wait for resources held by each other. Mitigation: acquire multiple mutexes in a consistent order across all tasks, or use a try-lock pattern with a timeout. Avoid holding a mutex while waiting for another resource.

Nondeterministic Timing

An RTOS introduces jitter due to context switches and interrupt handling. For hard real-time tasks, measure worst-case execution time (WCET) and ensure the task can complete within its deadline even under worst-case interference. Use a logic analyzer to capture actual timing.

ISR Overruns

If an ISR takes too long, it can delay other interrupts and cause the system to miss deadlines. Mitigation: keep ISRs short—ideally under 100 CPU cycles. Defer processing to a task using a semaphore or queue. Use nested interrupts carefully; some RTOS kernels allow interrupts to nest, but this increases complexity.

Mini-FAQ: Common Questions About Bare Metal and RTOS

This section addresses typical questions that arise when developers are learning or transitioning between architectures.

Can I use an RTOS on an 8-bit microcontroller?

Yes, but with limitations. 8-bit MCUs like the ATmega328P have very limited RAM (2 KB) and flash (32 KB). A lightweight RTOS like FreeRTOS can run, but you will have only 2–3 tasks with small stacks. For such constrained devices, bare metal is usually more practical unless you need strict timing separation.

How do I choose the tick rate?

The tick rate determines how often the scheduler runs. A common default is 100 Hz (10 ms tick). For systems that need sub-millisecond timing, you can increase the tick rate to 1 kHz, but this increases CPU overhead. Alternatively, use a tickless idle mode where the scheduler only runs when an event occurs—this reduces power consumption.

What is the best way to measure stack usage?

Most RTOS kernels provide a function like uxTaskGetStackHighWaterMark() that returns the minimum free stack space since the task started. Call this after the system has been running for a while to see the worst-case usage. Add a safety margin of 20–30% on top of that value.

Should I use an RTOS for a battery-powered device?

Yes, many RTOS kernels support tickless idle mode, which stops the tick timer when no task is ready to run. This reduces power consumption to near bare-metal levels. However, the RTOS itself adds some baseline current draw due to periodic timer wake-ups. Measure the actual power consumption in your application.

How do I debug RTOS issues?

Use the RTOS-aware debugging features in your IDE or a tool like SEGGER SystemView. These tools show task states, context switches, and interrupt activity over time. They are invaluable for diagnosing priority inversions, stack overflows, and timing issues.

Synthesis and Next Actions

Mastering embedded systems requires a pragmatic understanding of both bare-metal and RTOS approaches. There is no one-size-fits-all answer; the right choice depends on your project's complexity, timing constraints, and team experience. Start by evaluating your current or planned system's concurrency needs. If you have more than three independent activities that must meet deadlines, an RTOS is likely the better path. If you are building a simple, single-purpose device, bare metal will serve you well.

For those ready to adopt an RTOS, begin with a small, well-understood kernel like FreeRTOS. Follow the step-by-step transition process outlined in this guide, and be diligent about stack sizing, priority assignment, and synchronization. Use the tools available—stack watermarks, trace viewers, and logic analyzers—to validate your design. Remember that an RTOS is a tool, not a goal; the goal is reliable, maintainable firmware that meets its requirements.

Finally, keep learning. The embedded landscape evolves rapidly, with new kernels, hardware, and best practices emerging. Join community forums, read application notes from MCU vendors, and experiment with different architectures on development boards. The investment in understanding both bare metal and RTOS will pay dividends throughout your career.