Why RTOS over bare-metal in FreeRTOS - Why It Works This Way

Overview - Why RTOS over bare-metal

What is it?

RTOS stands for Real-Time Operating System. It is software that helps manage multiple tasks running on a microcontroller by organizing when and how each task runs. Bare-metal programming means writing code that runs directly on the hardware without any operating system. RTOS adds structure and timing control to embedded systems, making complex applications easier to build.

Why it matters

Without an RTOS, managing multiple tasks in embedded systems becomes complicated and error-prone, especially when timing is critical. RTOS solves this by handling task scheduling, timing, and resource sharing automatically. This makes devices more reliable and responsive, which is crucial in real-world applications like medical devices, automotive controls, or industrial machines.

Where it fits

Before learning about RTOS, you should understand basic microcontroller programming and how bare-metal code works. After mastering RTOS basics, you can explore advanced topics like inter-task communication, synchronization, and real-time scheduling algorithms.

Mental Model

Core Idea

An RTOS is like a smart traffic controller that organizes many tasks on a microcontroller so they run smoothly and on time, unlike bare-metal where you manage everything yourself.

Think of it like...

Imagine a busy kitchen with many cooks (tasks). Bare-metal is like having no manager, so cooks might bump into each other or forget orders. An RTOS is like a head chef who assigns tasks, times them, and ensures the kitchen runs efficiently without chaos.

┌───────────────┐
│   Application │
│ ┌───────────┐ │
│ │ Task 1    │ │
│ │ Task 2    │ │
│ │ Task 3    │ │
│ └───────────┘ │
│      RTOS     │
│ ┌───────────┐ │
│ │ Scheduler │ │
│ │ Timers    │ │
│ │ IPC       │ │
│ └───────────┘ │
└───────┬───────┘
        │
   ┌────▼─────┐
   │ Hardware │
   └──────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Bare-Metal Programming

Concept: Learn what bare-metal programming means and how code runs directly on hardware without an operating system.

Bare-metal programming means writing instructions that the microcontroller executes one after another. You control everything: when to read sensors, when to turn on LEDs, and how to respond to events. There is no built-in system to manage multiple tasks or timing, so you write all the logic yourself.

Result

You get full control but must carefully manage timing and task order manually.

Understanding bare-metal is essential because it shows why managing multiple tasks manually can become complex and error-prone.

2

Foundation

What is an RTOS?

Concept: Introduce the idea of an RTOS as software that manages multiple tasks and timing on a microcontroller.

An RTOS provides a scheduler that decides which task runs and when. It allows tasks to run seemingly at the same time by switching between them quickly. It also provides tools like timers and communication methods between tasks, making complex programs easier to write and maintain.

Result

Tasks can run concurrently with controlled timing and resource sharing.

Knowing what an RTOS does helps you see how it simplifies multitasking and timing compared to bare-metal.

3

Intermediate

Task Scheduling and Priorities

🤔Before reading on: do you think all tasks in an RTOS run equally or some get preference? Commit to your answer.

Concept: Learn how RTOS schedules tasks based on priority and timing requirements.

RTOS assigns priorities to tasks. Higher priority tasks run before lower priority ones. The scheduler switches tasks based on these priorities and timing rules, ensuring critical tasks get CPU time when needed. This prevents important tasks from being delayed by less important ones.

Result

Critical tasks run on time, improving system responsiveness.

Understanding priority-based scheduling explains how RTOS meets real-time requirements that bare-metal struggles with.

4

Intermediate

Handling Multiple Tasks Safely

🤔Before reading on: do you think tasks in an RTOS can share data safely without extra care? Commit to your answer.

Concept: Introduce synchronization and communication tools in RTOS to avoid conflicts between tasks.

When tasks share data or resources, conflicts can happen if they access at the same time. RTOS provides mechanisms like mutexes and queues to coordinate access safely. This prevents bugs like data corruption or crashes that are common in bare-metal multitasking.

Result

Tasks cooperate safely, avoiding errors from simultaneous access.

Knowing about synchronization tools reveals why RTOS is safer for complex multitasking than bare-metal.

5

Advanced

Real-Time Guarantees and Deadlines

🤔Before reading on: do you think bare-metal can guarantee task deadlines as reliably as an RTOS? Commit to your answer.

Concept: Explore how RTOS ensures tasks meet strict timing deadlines, unlike bare-metal.

RTOS uses deterministic scheduling algorithms to guarantee tasks run within set time limits. This is critical in systems like medical devices or automotive controls where delays can cause failures. Bare-metal systems often cannot guarantee this because timing depends on manual code flow and interrupts.

Result

Systems meet strict timing needs reliably.

Understanding real-time guarantees shows why RTOS is essential for safety-critical applications.

6

Expert

Trade-offs and Overhead of Using RTOS

🤔Before reading on: do you think RTOS always makes systems faster than bare-metal? Commit to your answer.

Concept: Learn about the costs and limitations of using an RTOS compared to bare-metal.

RTOS adds overhead from task switching, scheduling, and synchronization. This can use more memory and CPU time than bare-metal. In very simple or ultra-low-power systems, bare-metal might be better. Experts weigh these trade-offs when choosing between RTOS and bare-metal.

Result

You understand when RTOS benefits outweigh its costs.

Knowing RTOS overhead helps make informed design choices rather than assuming RTOS is always better.

Under the Hood

An RTOS runs a scheduler that manages a list of tasks, each with its own state and priority. The scheduler uses hardware timers and interrupts to switch the CPU between tasks quickly, saving and restoring their context (like registers and stack). It also manages synchronization objects to coordinate tasks safely. This happens transparently, so tasks appear to run simultaneously.

Why designed this way?

RTOS was designed to solve the complexity of managing multiple time-sensitive tasks on limited hardware. Early embedded systems struggled with timing and multitasking, so RTOS introduced structured scheduling and resource management. Alternatives like cooperative multitasking were simpler but less reliable, so preemptive RTOS became standard for real-time needs.

┌───────────────┐
│   Task List   │
│ ┌───────────┐ │
│ │ Task 1    │ │
│ │ Task 2    │ │
│ │ Task 3    │ │
│ └───────────┘ │
│      │        │
│      ▼        │
│  ┌─────────┐  │
│  │Scheduler│◄─┼─ Hardware Timer Interrupt
│  └─────────┘  │
│      │        │
│      ▼        │
│  CPU Context  │
│  Switch Save  │
│  and Restore  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does using an RTOS mean your program runs faster than bare-metal? Commit yes or no.

Common Belief: RTOS always makes programs run faster because it manages tasks efficiently.

Reality: RTOS adds overhead from task switching and scheduling, so raw execution speed can be slower than bare-metal.

Why it matters: Expecting RTOS to be faster can lead to poor performance choices in simple or timing-critical systems.

Quick: Can an RTOS guarantee all tasks run exactly at the same time? Commit yes or no.

Common Belief: RTOS runs multiple tasks simultaneously like a multi-core processor.

Reality: RTOS runs one task at a time on a single-core CPU by switching tasks rapidly, creating the illusion of concurrency.

Why it matters: Misunderstanding this can cause wrong assumptions about timing and resource use.

Quick: Is bare-metal always simpler and better for small projects? Commit yes or no.

Common Belief: Bare-metal is simpler and better for all small embedded projects.

Reality: Even small projects can benefit from RTOS features like timers and task management, improving reliability and scalability.

Why it matters: Avoiding RTOS due to this belief can cause harder maintenance and bugs as projects grow.

Quick: Does using an RTOS eliminate the need to understand hardware interrupts? Commit yes or no.

Common Belief: RTOS handles everything, so you don't need to know about interrupts anymore.

Reality: Understanding interrupts is still essential because RTOS relies on them for task switching and timing.

Why it matters: Ignoring interrupts can cause incorrect RTOS use and subtle bugs.

Expert Zone

1

RTOS task priorities can cause priority inversion, where a low-priority task blocks a high-priority one, requiring special protocols to handle.

2

The choice between preemptive and cooperative multitasking RTOS affects system responsiveness and complexity.

3

Memory footprint and power consumption of RTOS vary widely; tuning these is critical in embedded design.

When NOT to use

RTOS is not ideal for ultra-simple or ultra-low-power devices where overhead is unacceptable. In such cases, bare-metal or simple super-loop designs are better. Also, if timing requirements are loose and tasks are few, RTOS complexity may be unnecessary.

Production Patterns

In production, RTOS is used with layered software architectures separating hardware drivers, middleware, and application tasks. Developers use RTOS features like timers, queues, and event groups to build modular, maintainable systems. Debugging tools often integrate with RTOS to show task states and timing.

Connections

Multithreading in Desktop Operating Systems

RTOS multitasking is a simpler, real-time version of desktop multithreading.

Understanding desktop threads helps grasp RTOS tasks, but RTOS adds strict timing guarantees missing in general OSes.

Project Management

RTOS scheduling is like managing multiple project tasks with deadlines and priorities.

Knowing how to prioritize and schedule work in projects clarifies how RTOS manages tasks to meet deadlines.

Traffic Signal Control Systems

RTOS scheduling resembles traffic lights controlling vehicle flow to avoid collisions and delays.

Seeing RTOS as traffic control helps understand how it prevents task conflicts and ensures smooth operation.

Common Pitfalls

#1 Trying to run all tasks in a single infinite loop without timing control.

Wrong approach:

while(1) {
task1();
task2();
task3();
}

Correct approach:

Use RTOS tasks with priorities and let the scheduler switch between them.

Root cause:

Misunderstanding that bare-metal loops cannot handle multitasking reliably.

#2 Accessing shared data from multiple tasks without synchronization.

Wrong approach:

task1() {
shared_var = 5;
}
task2() {
if(shared_var == 5) do_something();
}

Correct approach:

Use mutexes or queues to protect shared_var access.

Root cause:

Ignoring concurrency issues leads to data corruption.

#3 Assuming RTOS eliminates all timing bugs automatically.

Wrong approach:

Relying on RTOS without setting correct task priorities or deadlines.

Correct approach:

Carefully design task priorities and use RTOS timing features to meet deadlines.

Root cause:

Overestimating RTOS capabilities without proper configuration.

Key Takeaways

Bare-metal programming means you control everything directly but must manage timing and multitasking manually.

RTOS provides a scheduler and tools to manage multiple tasks with priorities and timing guarantees.

Using an RTOS improves reliability and responsiveness in complex or time-critical embedded systems.

RTOS adds overhead and complexity, so it is not always the best choice for very simple or low-power devices.

Understanding RTOS internals and trade-offs helps make better design decisions and avoid common pitfalls.