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.

Practice

1. Why is using an RTOS often better than programming on bare-metal for complex embedded systems?

easy

A. Because bare-metal code runs faster without any overhead

B. Because RTOS requires no knowledge of hardware

C. Because RTOS handles multiple tasks with scheduling and timing automatically

D. Because bare-metal systems never crash

Solution

1. Step 1: Understand task management differences

   RTOS automatically manages multiple tasks with scheduling and timing, while bare-metal requires manual handling.

2. Step 2: Compare complexity and reliability

   RTOS improves reliability by handling task switching and timing, reducing manual errors common in bare-metal.

3. Final Answer:

   Because RTOS handles multiple tasks with scheduling and timing automatically -> Option C

4. Quick Check:

   RTOS manages tasks automatically [OK]

Hint: RTOS automates multitasking; bare-metal needs manual control [OK]

Common Mistakes:

• Thinking bare-metal is always faster without considering complexity
• Assuming RTOS removes need for hardware knowledge
• Believing bare-metal systems never crash

2. Which of the following is the correct way to create a task in FreeRTOS?

easy

A. xTaskCreate(TaskFunction, "TaskName", StackSize, NULL, Priority, NULL);

B. createTask(TaskFunction, Priority);

C. TaskCreate(TaskFunction, StackSize);

D. xCreateTask(TaskFunction, "TaskName");

Solution

1. Step 1: Recall FreeRTOS task creation syntax

   The correct function is xTaskCreate with parameters: function, name, stack size, parameters, priority, and task handle.

2. Step 2: Match options to syntax

   Only xTaskCreate(TaskFunction, "TaskName", StackSize, NULL, Priority, NULL); matches the correct FreeRTOS API call with all required parameters.

3. Final Answer:

   xTaskCreate(TaskFunction, "TaskName", StackSize, NULL, Priority, NULL); -> Option A

4. Quick Check:

   FreeRTOS task creation = xTaskCreate(...) [OK]

Hint: Remember FreeRTOS uses xTaskCreate with 6 parameters [OK]

Common Mistakes:

• Using incorrect function names like createTask
• Omitting required parameters
• Confusing parameter order

3. Given this FreeRTOS code snippet, what will be the output on the serial console?

void Task1(void *pvParameters) {
  for (;;) {
    printf("Task1 running\n");
    vTaskDelay(pdMS_TO_TICKS(1000));
  }
}

void Task2(void *pvParameters) {
  for (;;) {
    printf("Task2 running\n");
    vTaskDelay(pdMS_TO_TICKS(500));
  }
}

int main() {
  xTaskCreate(Task1, "Task1", 1000, NULL, 1, NULL);
  xTaskCreate(Task2, "Task2", 1000, NULL, 1, NULL);
  vTaskStartScheduler();
  return 0;
}

medium

A. Both tasks print at the same rate

B. Task1 prints twice as often as Task2

C. No output because scheduler is not started

D. Task2 prints twice as often as Task1

Solution

1. Step 1: Analyze delay times for each task

   Task1 delays 1000 ms between prints; Task2 delays 500 ms between prints.

2. Step 2: Compare print frequencies

   Task2 runs twice as often because 500 ms delay is half of 1000 ms delay.

3. Final Answer:

   Task2 prints twice as often as Task1 -> Option D

4. Quick Check:

   Shorter delay means more prints [OK]

Hint: Shorter vTaskDelay means more frequent prints [OK]

Common Mistakes:

• Confusing which task has shorter delay
• Assuming tasks run sequentially, not concurrently
• Ignoring vTaskStartScheduler call

4. This FreeRTOS code snippet does not behave as expected. What is the main problem?

void Task(void *pvParameters) {
  while(1) {
    // Do some work
    vTaskDelay(1000);
  }
}

int main() {
  xTaskCreate(Task, "Task", 1000, NULL, 1, NULL);
  vTaskStartScheduler();
  return 0;
}

medium

A. vTaskStartScheduler should be called before creating tasks

B. vTaskDelay needs pdMS_TO_TICKS macro for delay time

C. xTaskCreate missing priority parameter

D. Task function must return an int

Solution

1. Step 1: Check vTaskDelay usage

   vTaskDelay expects ticks, but 1000 is milliseconds; pdMS_TO_TICKS converts ms to ticks.

2. Step 2: Identify correct delay call

   Correct call is vTaskDelay(pdMS_TO_TICKS(1000)) to delay 1000 ms properly.

3. Final Answer:

   vTaskDelay needs pdMS_TO_TICKS macro for delay time -> Option B

4. Quick Check:

   Delay in ticks, not ms [OK]

Hint: Always convert ms to ticks with pdMS_TO_TICKS [OK]

Common Mistakes:

• Passing milliseconds directly to vTaskDelay
• Thinking task functions must return int
• Calling scheduler before creating tasks

5. You want to improve responsiveness in a sensor monitoring system by switching from bare-metal to FreeRTOS. Which approach best uses FreeRTOS features to achieve this?

hard

A. Create separate tasks for sensor reading, data processing, and communication with different priorities

B. Run all code sequentially in one task with long delays

C. Use FreeRTOS only to replace delay functions but keep one big task

D. Disable interrupts and rely on polling in a single task

Solution

1. Step 1: Identify how RTOS improves responsiveness

   RTOS allows multiple tasks with priorities, so critical tasks run promptly.

2. Step 2: Evaluate options for task design

   Creating separate tasks for sensor reading, processing, and communication with priorities uses RTOS strengths best.

3. Final Answer:

   Create separate tasks for sensor reading, data processing, and communication with different priorities -> Option A

4. Quick Check:

   Separate prioritized tasks improve responsiveness [OK]

Hint: Use multiple prioritized tasks for better responsiveness [OK]

Common Mistakes:

• Keeping all code in one task with delays
• Using RTOS only for delays, not multitasking
• Disabling interrupts reduces responsiveness