Why RTOS over bare-metal in FreeRTOS - Visual Breakdown

Concept Flow - Why RTOS over bare-metal

Start Program

↓

Choose bare-metal?

Yes→Single task runs

↓

No task switching

↓

Choose RTOS?

Yes→Multiple tasks run

↓

Tasks switch by scheduler

↓

Program ends

This flow shows the choice between bare-metal and RTOS: bare-metal runs one task at a time with no switching, RTOS runs multiple tasks with scheduler switching.

Execution Sample

FreeRTOS

void main() {
  while(1) {
    task1();
    task2();
  }
}

// RTOS runs tasks concurrently with scheduler

This code shows a bare-metal loop running tasks one after another; RTOS allows tasks to run concurrently with switching.

Execution Table

Step	Task Running	Scheduler Action	Output/Effect
1	task1	No scheduler (bare-metal)	task1 runs fully
2	task2	No scheduler (bare-metal)	task2 runs fully
3	task1	No scheduler (bare-metal)	task1 runs again
4	task1	Scheduler switches to task2 (RTOS)	task1 runs part, then switches
5	task2	Scheduler switches to task1 (RTOS)	task2 runs part, then switches
6	task1	Scheduler switches to task2 (RTOS)	task1 runs part again

💡 Bare-metal runs tasks sequentially with no switching; RTOS switches tasks to run concurrently.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 4	After Step 5	Final
Current Task	None	task1	task2	task1 (partial)	task2 (partial)	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 there is no scheduler to switch tasks, as shown in execution_table rows 1-3 where tasks run fully one by one.

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

RTOS uses a scheduler to switch tasks frequently, shown in execution_table rows 4-6 where tasks run partially and switch.

What happens if a task blocks or waits in bare-metal?

The whole program waits because no other task runs, unlike RTOS where scheduler can switch to other tasks.

Visual Quiz - 3 Questions

Look at the execution_table, what task is running at step 2?

A task1

B task2

C No task

D Scheduler

💡 Hint

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

At which step does the scheduler start switching tasks?

A Step 4

B Step 3

C Step 1

D Step 7

💡 Hint

Look for 'Scheduler switches' in the 'Scheduler Action' column in execution_table.

If we remove the scheduler, how would the 'Current Task' variable change after step 5?

A It would stay on task2 only

B It would keep switching tasks

C It would stay on task1 only

D It would stop running tasks

💡 Hint

Refer to variable_tracker 'Scheduler Active' and 'Current Task' values and execution_table rows 1-3.

Concept Snapshot

Bare-metal runs one task fully before next.
No task switching or scheduler.
RTOS uses scheduler to switch tasks.
Allows multitasking and better responsiveness.
RTOS handles blocking tasks without stopping all.
Choose RTOS for complex, multitask needs.

Full Transcript

This visual trace compares bare-metal and RTOS task running. Bare-metal runs tasks one after another without switching, shown in steps 1-3. RTOS uses a scheduler to switch tasks frequently, allowing multitasking, shown in steps 4-6. Variables track current task and scheduler status. Key moments clarify why bare-metal lacks switching and how RTOS multitasks. Quiz questions check understanding of task running and scheduler action. Summary: bare-metal is simple sequential running; RTOS enables multitasking with scheduler.

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