Why semaphores are needed in FreeRTOS - See It in Action

Why Semaphores Are Needed in FreeRTOS

📖 Scenario: Imagine you have a small kitchen where only one person can use the stove at a time. If two people try to cook at the same time, they might bump into each other or spoil the food. To avoid this, you use a simple rule: only one person can use the stove, and others wait their turn.In FreeRTOS, when multiple tasks want to use the same resource like a printer or a sensor, we need a way to control access so they don't interfere with each other. This is where semaphores come in.

🎯 Goal: You will create a simple FreeRTOS program that uses a semaphore to control access to a shared resource. This will show why semaphores are needed to avoid conflicts between tasks.

📋 What You'll Learn

Create two tasks that try to access a shared resource

Create a semaphore to control access to the shared resource

Use the semaphore to make sure only one task uses the resource at a time

Print messages to show when a task is using or waiting for the resource

💡 Why This Matters

🌍 Real World

In embedded systems, many tasks share hardware like sensors, displays, or communication ports. Semaphores ensure these tasks do not interfere with each other.

💼 Career

Understanding semaphores is essential for embedded software developers to write safe multitasking applications using FreeRTOS or similar real-time operating systems.

1

Create two tasks and a shared resource variable

Create two FreeRTOS tasks called Task1 and Task2. Also, create a global integer variable called shared_resource and set it to 0.

FreeRTOS

// Create two tasks Task1 and Task2
// Create a global int variable shared_resource and set it to 0

Hint

Use int shared_resource = 0; outside the tasks. Create two functions Task1 and Task2 with the correct signature.

2

Create a semaphore to control access

Create a binary semaphore called xSemaphore using xSemaphoreCreateBinary(). Then give the semaphore once using xSemaphoreGive(xSemaphore) in main() before starting the scheduler.

FreeRTOS

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

int shared_resource = 0;
SemaphoreHandle_t xSemaphore;

void Task1(void *pvParameters) {
    // Task1 code will go here
    for(;;) {
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void Task2(void *pvParameters) {
    // Task2 code will go here
    for(;;) {
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main(void) {
    xSemaphore = xSemaphoreCreateBinary();
    // Give the semaphore once here
    // Your code here
    xTaskCreate(Task1, "Task1", 1000, NULL, 1, NULL);
    xTaskCreate(Task2, "Task2", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
    for(;;);
}

Hint

Remember to include semphr.h and create xSemaphore as a SemaphoreHandle_t. Give the semaphore once before starting the scheduler.

3

Use the semaphore in tasks to access the shared resource

In both Task1 and Task2, use xSemaphoreTake(xSemaphore, portMAX_DELAY) before accessing shared_resource. Increase shared_resource by 1, print a message showing the task name and the new value, then call xSemaphoreGive(xSemaphore). Add a delay of 1000 ms after releasing the semaphore.

FreeRTOS

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

int shared_resource = 0;
SemaphoreHandle_t xSemaphore;

void Task1(void *pvParameters) {
    for(;;) {
        // Take semaphore
        // Access shared_resource
        // Print "Task1 accessed shared_resource: "
        // Give semaphore
        // Delay 1000 ms
        // Your code here
    }
}

void Task2(void *pvParameters) {
    for(;;) {
        // Take semaphore
        // Access shared_resource
        // Print "Task2 accessed shared_resource: "
        // Give semaphore
        // Delay 1000 ms
        // Your code here
    }
}

int main(void) {
    xSemaphore = xSemaphoreCreateBinary();
    xSemaphoreGive(xSemaphore);
    xTaskCreate(Task1, "Task1", 1000, NULL, 1, NULL);
    xTaskCreate(Task2, "Task2", 1000, NULL, 1, NULL);
    vTaskStartScheduler();
    for(;;);
}

Hint

Use xSemaphoreTake and xSemaphoreGive around the code that changes shared_resource. Print the task name and the new value.

4

Print the output showing semaphore control

Run the program and observe the printed messages. The output should show Task1 and Task2 accessing shared_resource one after another without overlap. Print statements are already in the tasks.

FreeRTOS

// Run the program and observe the output
// Your code here

Hint

Look at the printed messages. They should show that Task1 and Task2 take turns accessing the shared resource without conflict.

Practice

1. Why are semaphores needed in FreeRTOS when multiple tasks share a resource?

easy

A. To prevent tasks from accessing the resource at the same time and causing errors

B. To speed up the execution of all tasks simultaneously

C. To allow tasks to ignore each other and run independently

D. To increase the memory usage of the system

Solution

1. Step 1: Understand resource sharing in multitasking

   When multiple tasks share a resource, simultaneous access can cause data corruption or crashes.

2. Step 2: Role of semaphores in synchronization

   Semaphores act as signals to control access, allowing only one task at a time to use the resource safely.

3. Final Answer:

   To prevent tasks from accessing the resource at the same time and causing errors -> Option A

4. Quick Check:

   Semaphores prevent simultaneous access = A [OK]

Hint: Semaphores stop tasks from clashing over shared resources [OK]

Common Mistakes:

• Thinking semaphores speed up all tasks
• Believing tasks run independently without coordination
• Assuming semaphores increase memory usage

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

easy

A. xSemaphoreCreateBinary();

B. SemaphoreCreateBinary();

C. createBinarySemaphore();

D. newSemaphoreBinary();

Solution

1. Step 1: Recall FreeRTOS semaphore creation functions

   FreeRTOS provides the function xSemaphoreCreateBinary() to create a binary semaphore.

2. Step 2: Verify syntax correctness

   The function name must start with 'x' and match the exact FreeRTOS API naming conventions.

3. Final Answer:

   xSemaphoreCreateBinary(); -> Option A

4. Quick Check:

   Correct FreeRTOS binary semaphore function = D [OK]

Hint: FreeRTOS functions start with 'x' for handles [OK]

Common Mistakes:

• Using incorrect function names without 'x' prefix
• Confusing with other RTOS APIs
• Adding extra words to function names

3. Consider this FreeRTOS code snippet:

SemaphoreHandle_t sem = xSemaphoreCreateBinary();
xSemaphoreGive(sem);
if(xSemaphoreTake(sem, 0) == pdTRUE) {
    printf("Access granted\n");
} else {
    printf("Access denied\n");
}

What will be the output?

medium

A. Access denied

B. Access granted

C. Compilation error

D. No output

Solution

1. Step 1: Understand semaphore creation and initial state

   The binary semaphore is created and then given once, so it is available (count = 1).

2. Step 2: Check the take operation with zero wait

   The xSemaphoreTake tries to take the semaphore immediately (timeout 0). Since it was given before, it succeeds.

3. Final Answer:

   Access granted -> Option B

4. Quick Check:

   Semaphore given then taken immediately = Access granted [OK]

Hint: Semaphore given before take means immediate success [OK]

Common Mistakes:

• Assuming zero timeout means failure
• Forgetting to give semaphore before take
• Confusing binary semaphore initial state

4. This FreeRTOS code snippet tries to protect a shared resource:

SemaphoreHandle_t sem = xSemaphoreCreateBinary();
// Task A
xSemaphoreTake(sem, portMAX_DELAY);
// Access resource
xSemaphoreGive(sem);
// Task B
xSemaphoreTake(sem, portMAX_DELAY);
// Access resource
xSemaphoreGive(sem);

What is the main problem here?

medium

A. The semaphore is created as binary but used as counting

B. The semaphore is given twice causing overflow

C. The semaphore is never given initially, so tasks block forever

D. The tasks do not take the semaphore before accessing resource

Solution

1. Step 1: Check semaphore initial state after creation

   Binary semaphore created with xSemaphoreCreateBinary() starts empty (not given).

2. Step 2: Analyze task behavior on take

   Task A tries to take semaphore but it was never given, so it blocks forever. Same for Task B.

3. Final Answer:

   The semaphore is never given initially, so tasks block forever -> Option C

4. Quick Check:

   Binary semaphore must be given once before take = C [OK]

Hint: Binary semaphore must be given once before tasks take it [OK]

Common Mistakes:

• Assuming semaphore is given automatically on creation
• Thinking multiple gives cause overflow
• Ignoring semaphore take before resource access

5. You have two tasks sharing a sensor. Task 1 reads data and Task 2 processes it. Without semaphores, data corruption occurs. How should you use semaphores to fix this?

hard

A. Use a counting semaphore with count 0 to block both tasks

B. Use a mutex but never give it back after taking

C. Use no semaphore and rely on task priorities to avoid conflicts

D. Use a binary semaphore to let only one task access the sensor at a time

Solution

1. Step 1: Identify the problem of simultaneous access

   Both tasks accessing the sensor at the same time cause data corruption.

2. Step 2: Choose semaphore type and usage

   A binary semaphore ensures only one task accesses the sensor at a time, preventing conflicts.

3. Final Answer:

   Use a binary semaphore to let only one task access the sensor at a time -> Option D

4. Quick Check:

   Binary semaphore controls exclusive access = B [OK]

Hint: Binary semaphore allows one task access at a time [OK]

Common Mistakes:

• Using counting semaphore incorrectly with zero count
• Ignoring semaphore and trusting priorities alone
• Not releasing mutex causing deadlock