Why RTOS over bare-metal in FreeRTOS - See It in Action

Why RTOS over bare-metal

📖 Scenario: You are working on a small embedded device that controls home appliances. You want to understand why using a Real-Time Operating System (RTOS) like FreeRTOS can be better than writing code directly on bare-metal hardware.

🎯 Goal: Learn the basic difference between RTOS and bare-metal programming by creating a simple FreeRTOS task and comparing it with a bare-metal loop.

📋 What You'll Learn

Create a simple task function that toggles an LED

Set up a FreeRTOS scheduler to run the task

Create a bare-metal infinite loop that toggles the LED

Print output to show which method is running

💡 Why This Matters

🌍 Real World

Embedded devices like home appliances, wearables, and IoT gadgets often use RTOS to handle multiple functions smoothly.

💼 Career

Understanding RTOS vs bare-metal is key for embedded software engineers working on real-time systems.

1

Create a bare-metal infinite loop

Write a main function with an infinite while loop that toggles an LED by calling toggleLED() and prints "Bare-metal loop running" once per loop.

FreeRTOS

void main() {
    // Your code here
}

Hint

Use a while(1) loop inside main to run forever. Call toggleLED() and then print the message.

2

Create a FreeRTOS task function

Define a FreeRTOS task function called vLEDTask that toggles the LED by calling toggleLED() and prints "RTOS task running" inside an infinite loop with vTaskDelay(1000) to wait 1 second.

FreeRTOS

void toggleLED() {
    // Code to toggle LED hardware
}

int main() {
    while(1) {
        toggleLED();
        printf("Bare-metal loop running\n");
    }
    return 0;
}

// Your code here to define vLEDTask

Hint

Define a function with void vLEDTask(void *pvParameters). Inside, use an infinite loop to toggle the LED, print the message, and delay 1000 ticks.

3

Set up FreeRTOS scheduler and create the task

In main, create the FreeRTOS task vLEDTask using xTaskCreate and start the scheduler with vTaskStartScheduler(). Remove the bare-metal loop.

FreeRTOS

void toggleLED() {
    // Code to toggle LED hardware
}

void vLEDTask(void *pvParameters) {
    while(1) {
        toggleLED();
        printf("RTOS task running\n");
        vTaskDelay(1000);
    }
}

int main() {
    // Your code here to create task and start scheduler
    return 0;
}

Hint

Use xTaskCreate with vLEDTask and then call vTaskStartScheduler() to run the RTOS tasks.

4

Print comparison output

Add print statements before the bare-metal loop and before starting the FreeRTOS scheduler to show "Starting bare-metal loop" and "Starting RTOS scheduler" respectively. Run the program and observe the output.

FreeRTOS

void toggleLED() {
    // Code to toggle LED hardware
}

void vLEDTask(void *pvParameters) {
    while(1) {
        toggleLED();
        printf("RTOS task running\n");
        vTaskDelay(1000);
    }
}

int main() {
    // Your code here to add print statements
    xTaskCreate(vLEDTask, "LED Task", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
    return 0;
}

Hint

Print the message before creating the task and starting the scheduler. The output should show the RTOS messages.

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