Bare-metal vs RTOS execution model in Embedded C - Visual Side-by-Side Comparison

Concept Flow - Bare-metal vs RTOS execution model

Start

↓

Bare-metal

↓

Single main loop

↓

Tasks run one by one

↓

No preemption

↓

RTOS

↓

Multiple tasks

↓

Scheduler runs

↓

Tasks preempted & switched

↓

Concurrent task execution

↓

End

Shows the flow difference: Bare-metal runs one main loop with tasks sequentially, RTOS uses a scheduler to switch between tasks for concurrency.

Execution Sample

Embedded C

int main() {
  while(1) {
    task1();
    task2();
  }
  return 0;
}

// RTOS example
void task1() { /*...*/ }
void task2() { /*...*/ }

Bare-metal runs task1 and task2 one after another in an endless loop; RTOS runs tasks with a scheduler allowing task switching.

Execution Table

Step	Model	Action	Task Running	Scheduler Active	Notes
1	Bare-metal	Start main loop	None	No	System starts, no scheduler
2	Bare-metal	Run task1()	task1	No	task1 runs fully
3	Bare-metal	Run task2()	task2	No	task2 runs fully after task1
4	Bare-metal	Loop back	None	No	Repeat tasks sequentially
5	RTOS	Start scheduler	None	Yes	Scheduler begins managing tasks
6	RTOS	Run task1()	task1	Yes	task1 runs until preempted
7	RTOS	Preempt task1	task1	Yes	Scheduler switches tasks
8	RTOS	Run task2()	task2	Yes	task2 runs concurrently
9	RTOS	Switch back to task1	task1	Yes	Tasks switch repeatedly
10	RTOS	Continue scheduling	task1/task2	Yes	Concurrent multitasking
11	Exit	System runs indefinitely	N/A	N/A	No exit in embedded systems

💡 Embedded systems run indefinitely; no normal exit.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 6	After Step 8	Final
Task Running	None	task1	task2	task1	task2	task1/task2 switching
Scheduler Active	No	No	No	Yes	Yes	Yes

Key Moments - 3 Insights

Why does bare-metal run tasks one after another without switching?

Because bare-metal has no scheduler (see execution_table steps 2-4), tasks run fully before the next starts.

How does RTOS allow tasks to run seemingly at the same time?

RTOS uses a scheduler to preempt and switch tasks quickly (see execution_table steps 6-10), creating concurrency.

Does bare-metal system have a scheduler active at any point?

No, bare-metal systems do not have a scheduler (see variable_tracker Scheduler Active column at steps 2-4).

Visual Quiz - 3 Questions

Look at the execution_table at step 3, which task is running?

A task1

B None

C task2

D Scheduler

💡 Hint

Check the 'Task Running' column at step 3 in execution_table.

At which step does the scheduler become active in the RTOS model?

A Step 5

B Step 7

C Step 2

D Step 10

💡 Hint

Look at the 'Scheduler Active' column in execution_table.

If we remove the scheduler in RTOS, how would the 'Task Running' column change after step 6?

A Tasks would switch as usual

B Only task1 would run continuously

C Only task2 would run continuously

D No tasks would run

💡 Hint

Without scheduler (see variable_tracker), no preemption means task1 runs fully.

Concept Snapshot

Bare-metal: single main loop runs tasks sequentially with no switching.
RTOS: uses scheduler to switch tasks, enabling multitasking.
Bare-metal has no preemption; RTOS preempts tasks.
RTOS scheduler manages task timing and concurrency.
Embedded systems usually run indefinitely without exit.

Full Transcript

This visual execution compares bare-metal and RTOS execution models in embedded C. Bare-metal runs a single main loop executing tasks one after another without interruption. The execution table shows steps where task1 runs fully, then task2 runs fully, looping endlessly. The scheduler is inactive in bare-metal. In contrast, RTOS starts a scheduler that manages multiple tasks by preempting and switching between them rapidly. The execution table traces scheduler activation and task switching steps. Variable tracking shows which task runs and scheduler status at each step. Key moments clarify why bare-metal lacks task switching and how RTOS achieves concurrency. The quiz tests understanding of task running states and scheduler activation. The snapshot summarizes the main differences simply.

Practice

1. Which statement best describes the bare-metal execution model in embedded C?

easy

A. Multiple tasks run concurrently with a scheduler.

B. It requires an operating system to manage tasks.

C. Code runs directly on hardware with a single main loop.

D. It uses virtual machines to isolate processes.

Solution

1. Step 1: Understand bare-metal execution

   Bare-metal means the program runs directly on the hardware without an operating system.

2. Step 2: Identify the execution style

   Bare-metal typically uses a single main loop to control the program flow.

3. Final Answer:

   Code runs directly on hardware with a single main loop. -> Option C

4. Quick Check:

   Bare-metal = single main loop [OK]

Hint: Bare-metal means one main loop, no OS multitasking [OK]

Common Mistakes:

• Confusing bare-metal with RTOS multitasking
• Thinking bare-metal requires an OS
• Assuming bare-metal uses task scheduling

2. Which of the following is the correct way to start a task in an RTOS environment in embedded C?

easy

A. void startTask() { while(1) { /* task code */ } }

B. xTaskCreate(taskFunction, "Task", 1000, NULL, 1, NULL);

C. main() { runTask(); }

D. createThread(taskFunction);

Solution

1. Step 1: Recognize RTOS task creation syntax

   In embedded C with RTOS like FreeRTOS, tasks are created using xTaskCreate().

2. Step 2: Match the correct function call

   xTaskCreate(taskFunction, "Task", 1000, NULL, 1, NULL); uses xTaskCreate() with proper parameters to start a task.

3. Final Answer:

   xTaskCreate(taskFunction, "Task", 1000, NULL, 1, NULL); -> Option B

4. Quick Check:

   RTOS task start = xTaskCreate() [OK]

Hint: RTOS tasks start with xTaskCreate() function [OK]

Common Mistakes:

• Using infinite loops without RTOS task creation
• Calling non-existent functions like createThread()
• Starting tasks directly in main() without scheduler

3. Given the following code snippet in a bare-metal system:

int main() {
  while(1) {
    toggleLED();
  }
  return 0;
}

What will happen when this runs?

medium

A. The LED toggles continuously without stopping.

B. The program creates multiple tasks to toggle the LED.

C. The LED toggles once and the program ends.

D. The program will cause a runtime error.

Solution

1. Step 1: Analyze the infinite loop

   The while(1) loop runs forever, repeatedly calling toggleLED().

2. Step 2: Understand bare-metal behavior

   Since there is no OS, the program stays in this loop, toggling the LED continuously.

3. Final Answer:

   The LED toggles continuously without stopping. -> Option A

4. Quick Check:

   Infinite loop toggles LED forever [OK]

Hint: Infinite loop means continuous action in bare-metal [OK]

Common Mistakes:

• Thinking tasks are created automatically
• Assuming program ends after one toggle
• Expecting runtime errors without cause

4. In an RTOS program, the following code snippet causes the LED to toggle only once:

void taskLED(void *params) {
  toggleLED();
}

int main() {
  xTaskCreate(taskLED, "LED", 1000, NULL, 1, NULL);
  vTaskStartScheduler();
  while(1) {}
}

What is the main problem?

medium

A. The task function lacks an infinite loop to keep running.

B. The scheduler is not started properly.

C. The task priority is too low to run.

D. The LED toggle function is incorrect.

Solution

1. Step 1: Check the task function structure

   The task function runs toggleLED() once and then returns, ending the task immediately.

2. Step 2: Understand RTOS task lifetime

   RTOS tasks must have an infinite loop to keep running and performing actions repeatedly.

3. Final Answer:

   The task function lacks an infinite loop to keep running. -> Option A

4. Quick Check:

   RTOS tasks need infinite loops [OK]

Hint: RTOS tasks must loop forever to keep running [OK]

Common Mistakes:

• Forgetting infinite loop in task function
• Assuming scheduler auto-repeats tasks
• Blaming LED function without checking task code

5. You have a project that needs to read sensor data, control motors, and communicate over UART simultaneously. Which execution model is best and why?

hard

A. Bare-metal, because it is simpler and uses one main loop.

B. Bare-metal, because multitasking is not possible in RTOS.

C. RTOS, but only if the hardware supports virtual machines.

D. RTOS, because it can run multiple tasks concurrently with scheduling.

Solution

1. Step 1: Analyze project requirements

   The project needs to handle sensor reading, motor control, and UART communication at the same time.

2. Step 2: Match execution model to multitasking needs

   RTOS supports multiple tasks running concurrently with a scheduler, ideal for complex multitasking.

3. Final Answer:

   RTOS, because it can run multiple tasks concurrently with scheduling. -> Option D

4. Quick Check:

   Multitasking needs = RTOS [OK]

Hint: Use RTOS for multitasking, bare-metal for simple loops [OK]

Common Mistakes:

• Choosing bare-metal for complex multitasking
• Thinking RTOS can't multitask
• Confusing virtual machines with RTOS requirements