Why event groups coordinate tasks in FreeRTOS - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use event groups in FreeRTOS?

In FreeRTOS, event groups help tasks coordinate by setting and waiting for bits. What is the main reason tasks use event groups to coordinate?

A To provide a way for tasks to share memory safely without synchronization

B To replace queues for sending large data between tasks

C To allow multiple tasks to wait for multiple events simultaneously using bits in a single variable

D To create periodic timers that trigger task execution

💡 Hint

Think about how event groups use bits to signal multiple events at once.

Event groups let tasks wait for one or more bits to be set, allowing efficient coordination of multiple events in a single variable.

❓ Predict Output

intermediate

Output of event group synchronization example

Given the following FreeRTOS code snippet, what will be the output printed by the task waiting on the event group?

FreeRTOS

EventGroupHandle_t xEventGroup = xEventGroupCreate();

void vTask1(void *pvParameters) {
    xEventGroupSetBits(xEventGroup, (1 << 0));
    vTaskDelay(pdMS_TO_TICKS(100));
    xEventGroupSetBits(xEventGroup, (1 << 1));
    vTaskDelete(NULL);
}

void vTask2(void *pvParameters) {
    EventBits_t uxBits = xEventGroupWaitBits(
        xEventGroup,
        (1 << 0) | (1 << 1),
        pdTRUE,
        pdTRUE,
        portMAX_DELAY
    );
    if ((uxBits & ((1 << 0) | (1 << 1))) == ((1 << 0) | (1 << 1))) {
        printf("Both bits set\n");
    } else {
        printf("Bits not set\n");
    }
    vTaskDelete(NULL);
}

A Both bits set

B Compilation error due to missing event group initialization

C Bits not set

D Deadlock, task never prints

💡 Hint

Consider the order and timing of bits being set and waited on.

Task1 sets bit 0, then after 100ms sets bit 1. Task2 waits for both bits to be set before continuing, so it prints "Both bits set".

🔧 Debug

advanced

Identify the error in event group usage

What is the error in the following FreeRTOS code snippet that uses event groups to coordinate tasks?

FreeRTOS

EventGroupHandle_t xEventGroup;

void vTask1(void *pvParameters) {
    xEventGroupSetBits(xEventGroup, (1 << 0));
    vTaskDelete(NULL);
}

void vTask2(void *pvParameters) {
    EventBits_t bits = xEventGroupWaitBits(xEventGroup, (1 << 0), pdTRUE, pdFALSE, portMAX_DELAY);
    if (bits & (1 << 0)) {
        printf("Bit 0 received\n");
    }
    vTaskDelete(NULL);
}

int main(void) {
    vTaskStartScheduler();
    return 0;
}

A xEventGroupWaitBits uses incorrect parameters for clearing bits

B xEventGroupSetBits is called with wrong bit mask syntax

C vTaskStartScheduler is called before creating tasks

D xEventGroup is not created before use, causing a NULL pointer dereference

💡 Hint

Check if the event group handle is initialized before use.

The event group handle xEventGroup is declared but never created with xEventGroupCreate(), so it is NULL and causes a crash when used.

📝 Syntax

advanced

Correct syntax for waiting on multiple event bits

Which option shows the correct syntax to wait for bits 0 and 2 to be set in a FreeRTOS event group, clearing the bits on exit and waiting for both bits?

A xEventGroupWaitBits(xEventGroup, (1 << 0) | (1 << 2), pdFALSE, pdFALSE, portMAX_DELAY);

B xEventGroupWaitBits(xEventGroup, (1 << 0) | (1 << 2), pdTRUE, pdTRUE, portMAX_DELAY);

C xEventGroupWaitBits(xEventGroup, (1 << 0) + (1 << 2), pdFALSE, pdTRUE, portMAX_DELAY);

D xEventGroupWaitBits(xEventGroup, (1 << 0) & (1 << 2), pdTRUE, pdTRUE, portMAX_DELAY);

💡 Hint

Use bitwise OR to combine bits and set clear on exit and wait for all bits flags correctly.

To wait for bits 0 and 2, combine with bitwise OR. pdTRUE for clear on exit and pdTRUE for wait for all bits.

🚀 Application

expert

How event groups improve task coordination efficiency

In a FreeRTOS system with multiple tasks waiting on different events, why are event groups more efficient than using multiple binary semaphores for coordination?

A Because event groups allow waiting on multiple events simultaneously with a single wait call, reducing CPU overhead

B Because event groups use less memory than any semaphore or mutex

C Because event groups automatically prioritize tasks based on event bits set

D Because event groups guarantee task execution order without priority inversion

💡 Hint

Think about how waiting on multiple events with one call compares to waiting on many semaphores separately.

Event groups let tasks wait for multiple events at once, reducing the number of blocking calls and context switches, which improves efficiency.

Practice

1. What is the main purpose of event groups in FreeRTOS?

easy

A. To handle hardware interrupts directly

B. To create new tasks dynamically

C. To let tasks wait for or signal events using bits

D. To manage memory allocation

Solution

1. Step 1: Understand event groups role

   Event groups use bits to represent events that tasks can wait for or signal.

2. Step 2: Compare with other options

   Creating tasks, managing memory, and handling interrupts are different FreeRTOS features.

3. Final Answer:

   To let tasks wait for or signal events using bits -> Option C

4. Quick Check:

   Event groups coordinate tasks by signaling bits [OK]

Hint: Event groups use bits to sync tasks quickly [OK]

Common Mistakes:

• Confusing event groups with task creation
• Thinking event groups manage memory
• Assuming event groups handle interrupts

2. Which of the following is the correct way to create an event group in FreeRTOS?

easy

A. vEventGroupCreate()

B. xEventGroupCreate()

C. xCreateEventGroup()

D. vCreateEventGroup()

Solution

1. Step 1: Recall FreeRTOS naming conventions

   Functions returning handles usually start with 'x' and create functions end with 'Create'.

2. Step 2: Identify correct function

   The correct function to create an event group is xEventGroupCreate().

3. Final Answer:

   xEventGroupCreate() -> Option B

4. Quick Check:

   Event group creation uses xEventGroupCreate() [OK]

Hint: Creation functions start with 'x' and end with 'Create' [OK]

Common Mistakes:

• Using 'v' prefix which is for void functions
• Swapping function name order
• Assuming event groups are created with task functions

3. Given the code snippet:

EventGroupHandle_t xEventGroup = xEventGroupCreate();
const EventBits_t BIT_0 = (1 << 0);
xEventGroupSetBits(xEventGroup, BIT_0);
EventBits_t uxBits = xEventGroupWaitBits(xEventGroup, BIT_0, pdTRUE, pdFALSE, portMAX_DELAY);

What will be the value of uxBits after xEventGroupWaitBits returns?

medium

A. BIT_0

B. portMAX_DELAY

C. 0

D. pdTRUE

Solution

1. Step 1: Understand bit setting and waiting

   BIT_0 is set before waiting, so the wait function will return with BIT_0 set.

2. Step 2: Analyze parameters

   pdTRUE clears the bits after return, but uxBits holds the bits that were set when the function returned.

3. Final Answer:

   BIT_0 -> Option A

4. Quick Check:

   Wait returns bits that were set, here BIT_0 [OK]

Hint: Wait returns bits set before clearing if pdTRUE used [OK]

Common Mistakes:

• Assuming bits clear before return
• Confusing return value with delay constant
• Ignoring bit mask value

4. Identify the error in this FreeRTOS event group usage:

EventGroupHandle_t xEventGroup;
xEventGroupSetBits(xEventGroup, (1 << 1));

medium

A. Event groups cannot set bits directly

B. Bit mask (1 << 1) is invalid

C. xEventGroupSetBits requires a pointer to the event group

D. xEventGroup is not initialized before use

Solution

1. Step 1: Check event group initialization

   xEventGroup is declared but never created or assigned a valid handle.

2. Step 2: Understand function requirements

   xEventGroupSetBits requires a valid event group handle, which is missing here.

3. Final Answer:

   xEventGroup is not initialized before use -> Option D

4. Quick Check:

   Event group must be created before setting bits [OK]

Hint: Always create event group before using it [OK]

Common Mistakes:

• Using uninitialized event group handle
• Misunderstanding bit mask validity
• Passing pointer instead of handle

5. You want two tasks to wait until both have signaled readiness using event groups. Which approach correctly coordinates this?

hard

A. Each task sets a unique bit; both wait for both bits set before proceeding

B. Both tasks set the same bit and wait for that bit to be set

C. Tasks use separate event groups and wait independently

D. Tasks use a global variable instead of event groups

Solution

1. Step 1: Understand event group bits for coordination

   Each task sets a unique bit representing its readiness.

2. Step 2: Wait for both bits set

   Tasks wait for the combination of both bits to be set before continuing.

3. Final Answer:

   Each task sets a unique bit; both wait for both bits set before proceeding -> Option A

4. Quick Check:

   Unique bits per task coordinate readiness [OK]

Hint: Use unique bits per task and wait for all bits [OK]

Common Mistakes:

• Using same bit for multiple tasks
• Using separate event groups losing coordination
• Ignoring event groups and using variables