Why design patterns ensure reliable multi-tasking in FreeRTOS - See It in Action

Why design patterns ensure reliable multi-tasking

📖 Scenario: You are working on a small embedded system using FreeRTOS. You want to understand how design patterns help make multi-tasking reliable and safe. This project will guide you through creating tasks, using synchronization, and showing how design patterns prevent problems like data corruption.

🎯 Goal: Build a simple FreeRTOS program with two tasks sharing a variable safely using a mutex. This shows how design patterns like mutual exclusion ensure reliable multi-tasking.

📋 What You'll Learn

Create two FreeRTOS tasks named Task1 and Task2

Create a shared integer variable called sharedCounter initialized to 0

Create a mutex called xMutex to protect access to sharedCounter

In each task, safely increment sharedCounter 5 times using the mutex

Print the value of sharedCounter after each increment

Use FreeRTOS API functions like xTaskCreate, xSemaphoreCreateMutex, xSemaphoreTake, and xSemaphoreGive

💡 Why This Matters

🌍 Real World

Embedded systems often run multiple tasks that share resources. Using design patterns like mutexes prevents bugs and crashes.

💼 Career

Understanding synchronization and design patterns is essential for embedded software engineers working with real-time operating systems like FreeRTOS.

1

Create shared variable and include FreeRTOS headers

Write code to include FreeRTOS.h and task.h. Then create a global integer variable called sharedCounter and set it to 0.

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"

// Your code here

Hint

Remember to include the FreeRTOS headers first. Then declare sharedCounter as a global variable initialized to zero.

2

Create a mutex to protect sharedCounter

Create a mutex handle variable called xMutex of type SemaphoreHandle_t. Then create the mutex using xSemaphoreCreateMutex() and assign it to xMutex.

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"

int sharedCounter = 0;

// Your code here

Hint

Use SemaphoreHandle_t to declare the mutex variable. Then call xSemaphoreCreateMutex() to create it.

3

Create two tasks that safely increment sharedCounter

Write two task functions named Task1 and Task2. Each task should loop 5 times. Inside the loop, use xSemaphoreTake(xMutex, portMAX_DELAY) to lock the mutex, increment sharedCounter by 1, print the value using printf, then release the mutex with xSemaphoreGive(xMutex). Add a small delay of 100ms between increments using vTaskDelay(pdMS_TO_TICKS(100)).

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"

int sharedCounter = 0;
SemaphoreHandle_t xMutex;

void setupMutex() {
    xMutex = xSemaphoreCreateMutex();
}

// Write Task1 and Task2 functions below
// Your code here

Hint

Each task must lock the mutex before changing sharedCounter and unlock it after. Use printf to show the current value.

4

Create tasks and start the scheduler

In main(), call setupMutex(). Then create Task1 and Task2 using xTaskCreate with stack size 1000 and priority 1. Finally, start the FreeRTOS scheduler with vTaskStartScheduler(). Print "Scheduler started" before starting the scheduler.

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include 

int sharedCounter = 0;
SemaphoreHandle_t xMutex;

void setupMutex() {
    xMutex = xSemaphoreCreateMutex();
}

void Task1(void *pvParameters) {
    for (int i = 0; i < 5; i++) {
        xSemaphoreTake(xMutex, portMAX_DELAY);
        sharedCounter++;
        printf("Task1 incremented sharedCounter to %d\n", sharedCounter);
        xSemaphoreGive(xMutex);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
    vTaskDelete(NULL);
}

void Task2(void *pvParameters) {
    for (int i = 0; i < 5; i++) {
        xSemaphoreTake(xMutex, portMAX_DELAY);
        sharedCounter++;
        printf("Task2 incremented sharedCounter to %d\n", sharedCounter);
        xSemaphoreGive(xMutex);
        vTaskDelay(pdMS_TO_TICKS(100));
    }
    vTaskDelete(NULL);
}

int main(void) {
    // Your code here
}

Hint

Call setupMutex() first. Then create both tasks with xTaskCreate. Finally, start the scheduler with vTaskStartScheduler().

Practice

1. Why do design patterns help ensure reliable multi-tasking in FreeRTOS?

easy

A. They make tasks run faster by skipping synchronization.

B. They organize tasks to safely share resources and avoid conflicts.

C. They allow tasks to ignore priority rules.

D. They remove the need for task communication.

Solution

1. Step 1: Understand task coordination

   Design patterns help tasks work together by managing how they share resources.

2. Step 2: Recognize safety and reliability

   By organizing resource access, patterns prevent conflicts and crashes in multi-tasking.

3. Final Answer:

   They organize tasks to safely share resources and avoid conflicts. -> Option B

4. Quick Check:

   Safe resource sharing = Reliable multi-tasking [OK]

Hint: Think: patterns keep tasks from stepping on each other [OK]

Common Mistakes:

• Assuming patterns speed up tasks by skipping safety
• Believing tasks can ignore priorities safely
• Thinking communication is unnecessary

2. Which FreeRTOS feature is commonly used in design patterns to protect shared resources?

easy

A. Software timers

B. Task notifications

C. Mutexes

D. Event groups

Solution

1. Step 1: Identify resource protection tools

   Mutexes are designed to lock resources so only one task uses them at a time.

2. Step 2: Match with design pattern usage

   Design patterns use mutexes to avoid conflicts when tasks share data or hardware.

3. Final Answer:

   Mutexes -> Option C

4. Quick Check:

   Mutex = Resource protection [OK]

Hint: Mutexes lock resources to prevent conflicts [OK]

Common Mistakes:

• Confusing mutexes with timers or notifications
• Thinking event groups protect resources
• Assuming software timers manage resource access

3. Given this FreeRTOS code snippet, what is the expected output?

SemaphoreHandle_t mutex = xSemaphoreCreateMutex();

void Task1(void *pvParameters) {
  if (xSemaphoreTake(mutex, portMAX_DELAY) == pdTRUE) {
    printf("Task1 running\n");
    xSemaphoreGive(mutex);
  }
  vTaskDelete(NULL);
}

void Task2(void *pvParameters) {
  if (xSemaphoreTake(mutex, portMAX_DELAY) == pdTRUE) {
    printf("Task2 running\n");
    xSemaphoreGive(mutex);
  }
  vTaskDelete(NULL);
}

medium

A. Task1 running or Task2 running, but never both at the same time

B. Task2 running\nTask1 running

C. No output because mutex is never given

D. Task1 running\nTask2 running

Solution

1. Step 1: Understand mutex behavior in tasks

   Mutex allows only one task to enter the critical section at a time, so tasks run their print statements one after another.

2. Step 2: Analyze output possibilities

   Either Task1 or Task2 prints first, then the other prints after mutex is released; they never print simultaneously.

3. Final Answer:

   Task1 running or Task2 running, but never both at the same time -> Option A

4. Quick Check:

   Mutex serializes output = Task1 running or Task2 running, but never both at the same time [OK]

Hint: Mutex lets only one task print at a time [OK]

Common Mistakes:

• Assuming both print simultaneously
• Thinking mutex is never released
• Expecting fixed order of task execution

4. What is wrong with this FreeRTOS design pattern code snippet?

void TaskA(void *pvParameters) {
  xSemaphoreTake(mutex, 0);
  // critical section code
  xSemaphoreGive(mutex);
  vTaskDelete(NULL);
}

medium

A. Using zero block time may cause task to skip critical section without waiting.

B. Mutex is given before taking it.

C. vTaskDelete should be called before giving mutex.

D. Critical section code is missing.

Solution

1. Step 1: Analyze semaphore take with zero block time

   Using zero block time means the task tries to take the mutex but does not wait if it's unavailable, possibly skipping the critical section.

2. Step 2: Understand impact on reliability

   This can cause unreliable behavior because the task may not execute the critical section safely every time.

3. Final Answer:

   Using zero block time may cause task to skip critical section without waiting. -> Option A

4. Quick Check:

   Zero wait risks skipping mutex [OK]

Hint: Zero wait means no blocking; task may skip critical section [OK]

Common Mistakes:

• Thinking mutex is given before taken
• Believing vTaskDelete order matters here
• Assuming critical section must be shown

5. You want to design a FreeRTOS system where multiple tasks send data safely to a single processing task without data loss or corruption. Which design pattern best ensures reliable multi-tasking?

hard

A. Use a shared global variable without synchronization.

B. Use multiple mutexes for each task to lock the processor.

C. Use task notifications to broadcast data to all tasks.

D. Use a queue to send data from tasks to the processing task.

Solution

1. Step 1: Identify safe data transfer method

   Queues in FreeRTOS safely store data from multiple tasks and deliver it to one consumer task without corruption.

2. Step 2: Compare other options

   Shared variables without sync risk corruption; multiple mutexes locking processor is inefficient; task notifications are for signaling, not data transfer.

3. Final Answer:

   Use a queue to send data from tasks to the processing task. -> Option D

4. Quick Check:

   Queue = Safe multi-task data transfer [OK]

Hint: Queues safely pass data between tasks [OK]

Common Mistakes:

• Using shared variables without locks
• Misusing mutexes to lock processor
• Confusing notifications with data queues