Event group for task synchronization in FreeRTOS - Deep Dive

Overview - Event group for task synchronization

What is it?

An event group in FreeRTOS is a way for multiple tasks to communicate and synchronize by setting and waiting for bits in a shared variable. Each bit in the event group represents a different event or condition. Tasks can wait for one or more bits to be set before continuing, allowing them to coordinate their actions easily. This helps tasks work together without constantly checking each other's status.

Why it matters

Without event groups, tasks would have to use more complicated or less efficient methods to coordinate, like busy waiting or multiple semaphores. This can waste CPU time and make programs harder to understand and maintain. Event groups provide a simple, efficient way to signal multiple events and synchronize tasks, improving performance and clarity in real-time systems.

Where it fits

Before learning event groups, you should understand basic FreeRTOS concepts like tasks, semaphores, and queues. After mastering event groups, you can explore more advanced synchronization methods like task notifications and message buffers, or learn how to design complex real-time systems with multiple interacting tasks.

Mental Model

Core Idea

Event groups let tasks set and wait for specific bits in a shared flag variable to synchronize their actions efficiently.

Think of it like...

Imagine a group of friends sharing a whiteboard with checkboxes for different chores. Each friend ticks the boxes when they finish a chore. Others wait until certain boxes are ticked before starting their tasks. The whiteboard is like the event group, and the checkboxes are the bits representing events.

┌─────────────────────────────┐
│        Event Group          │
│  ┌─────┬─────┬─────┬─────┐  │
│  │ Bit0│ Bit1│ Bit2│ Bit3│  │
│  └─────┴─────┴─────┴─────┘  │
│                             │
│ Tasks wait for bits to be set│
│ Tasks set bits to signal events│
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding FreeRTOS Tasks and Synchronization

Concept: Learn what tasks are and why they need to synchronize in FreeRTOS.

FreeRTOS runs multiple tasks that share the CPU. Sometimes tasks must wait for others to finish or signal that something happened. Synchronization means coordinating tasks so they don't interfere or run too early. Common tools include semaphores and queues, but event groups offer a way to wait for multiple events at once.

Result

You understand why tasks need to coordinate and the basics of synchronization tools.

Knowing why tasks must synchronize helps you appreciate why event groups are useful and when to use them.

2

Foundation

What is an Event Group in FreeRTOS?

Concept: Introduce the event group as a shared variable with bits representing events.

An event group is a special FreeRTOS object holding a set of bits (flags). Each bit can be set (1) or cleared (0). Tasks can set bits to signal events or wait until certain bits are set before continuing. This lets tasks synchronize on multiple events using one variable.

Result

You can describe an event group as a collection of bits used for signaling between tasks.

Understanding event groups as bits in a shared variable clarifies how multiple events can be tracked efficiently.

3

Intermediate

Setting and Waiting for Event Bits

🤔Before reading on: do you think tasks can wait for multiple bits at once or only one bit? Commit to your answer.

Concept: Learn how tasks set bits and wait for one or more bits with options for all or any bits.

Tasks use xEventGroupSetBits() to set bits signaling events. To wait, tasks call xEventGroupWaitBits(), specifying which bits to wait for. They can wait for all bits to be set (AND) or any bit (OR). The function can also clear bits automatically after waiting. This flexibility lets tasks synchronize precisely.

Result

You know how to signal events and wait for one or more bits with control over conditions.

Knowing how to wait for all or any bits lets you design flexible synchronization schemes tailored to your tasks' needs.

4

Intermediate

Using Event Groups for Multiple Task Coordination

🤔Before reading on: do you think event groups can coordinate more than two tasks at once? Commit to your answer.

Concept: Explore how multiple tasks can use event groups to coordinate complex workflows.

Multiple tasks can set and wait on different bits in the same event group. For example, Task A waits for bits 1 and 2, set by Tasks B and C respectively. This allows tasks to wait for multiple conditions from different sources before proceeding. Event groups simplify complex synchronization without many semaphores.

Result

You understand how event groups enable coordination among many tasks using shared bits.

Recognizing event groups as a multi-bit signaling hub helps you manage complex task dependencies cleanly.

5

Intermediate

Clearing Bits and Auto-Clear Behavior

Concept: Learn how bits can be cleared manually or automatically after a task wakes up.

When waiting on bits, tasks can request bits to be cleared automatically after the wait returns. This prevents stale signals from affecting future waits. Alternatively, bits can be cleared manually using xEventGroupClearBits(). Proper clearing ensures tasks respond only to new events.

Result

You know how to manage event bits lifecycle to avoid false triggers.

Understanding bit clearing prevents bugs where tasks react multiple times to the same event.

6

Advanced

Event Groups vs Other Synchronization Methods

🤔Before reading on: do you think event groups are always better than semaphores? Commit to your answer.

Concept: Compare event groups with semaphores and task notifications to understand strengths and limits.

Event groups allow waiting on multiple events simultaneously, unlike binary semaphores which signal one event. Task notifications are lightweight but limited to one notification per task. Event groups are ideal when multiple events must be tracked together. However, they use more memory and have some overhead.

Result

You can choose the right synchronization tool based on task needs and resource constraints.

Knowing trade-offs helps you pick synchronization methods that balance efficiency and complexity.

7

Expert

Internal Implementation and Atomicity Guarantees

🤔Before reading on: do you think setting or waiting on bits can cause race conditions? Commit to your answer.

Concept: Understand how FreeRTOS implements event groups to ensure thread-safe bit manipulation.

Event groups use atomic operations and critical sections internally to prevent race conditions when multiple tasks set or wait on bits simultaneously. The kernel disables interrupts briefly during bit changes to keep operations safe. This guarantees that bits reflect consistent states even under heavy multitasking.

Result

You grasp how event groups maintain data integrity in concurrent environments.

Understanding atomicity in event groups prevents subtle bugs and informs safe usage in complex systems.

Under the Hood

Event groups are implemented as a 32-bit variable where each bit represents an event flag. When a task sets or clears bits, FreeRTOS uses critical sections to disable interrupts briefly, ensuring no other task or interrupt can change the bits simultaneously. Waiting tasks block on a queue associated with the event group, and when bits change to meet the wait condition, the kernel unblocks the waiting tasks. This mechanism ensures safe, efficient synchronization without busy waiting.

Why designed this way?

FreeRTOS event groups were designed to provide a lightweight, flexible way to wait on multiple events simultaneously. Using bits in a single variable minimizes memory and CPU overhead compared to multiple semaphores. The atomic operations and critical sections ensure thread safety in a real-time environment where tasks and interrupts run concurrently. Alternatives like multiple semaphores were more resource-heavy and complex to manage.

┌───────────────────────────────┐
│       Event Group (32-bit)    │
│  ┌─────┬─────┬─────┬─────┐    │
│  │ Bit0│ Bit1│ Bit2│ Bit3│ ...│
│  └─────┴─────┴─────┴─────┘    │
│           │                   │
│  ┌────────┴────────┐          │
│  │ Critical Section │          │
│  └────────┬────────┘          │
│           │                   │
│  ┌────────┴────────┐          │
│  │ Atomic Bit Ops  │          │
│  └────────┬────────┘          │
│           │                   │
│  ┌────────┴────────┐          │
│  │ Task Wait Queue │◄─────────┤
│  └─────────────────┘          │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can a task wait for bits without blocking the CPU? Commit yes or no.

Common Belief: Waiting on event group bits always wastes CPU time because tasks keep checking bits in a loop.

Reality: Tasks block and sleep while waiting on event group bits, so the CPU is free to run other tasks until the event occurs.

Why it matters: Believing waiting wastes CPU leads to inefficient designs with busy loops, reducing system responsiveness and battery life.

Quick: Does setting a bit in an event group automatically clear it after a task wakes? Commit yes or no.

Common Belief: Once a bit is set in an event group, it stays set forever until manually cleared.

Reality: Bits can be automatically cleared after a task wakes if the wait function is called with the auto-clear option.

Why it matters: Not knowing about auto-clear can cause tasks to react multiple times to the same event, causing logic errors.

Quick: Can event groups replace all synchronization methods? Commit yes or no.

Common Belief: Event groups are the best synchronization method and should always be used instead of semaphores or queues.

Reality: Event groups are powerful but not always the best choice; semaphores and queues have simpler or more efficient use cases.

Why it matters: Misusing event groups can lead to unnecessary complexity or resource use, hurting system performance.

Quick: Are event group bits shared safely between tasks without extra precautions? Commit yes or no.

Common Belief: Tasks can set and clear event group bits without worrying about race conditions or data corruption.

Reality: FreeRTOS internally protects event group bit operations with atomic actions and critical sections to prevent race conditions.

Why it matters: Assuming no protection leads to incorrect manual attempts to protect bits, causing bugs or deadlocks.

Expert Zone

1

Event groups use a 32-bit integer, so only 32 distinct events can be tracked per group, which can limit design choices in large systems.

2

The auto-clear feature of event groups can cause subtle bugs if multiple tasks wait on the same bits without careful design.

3

Event groups can be combined with task notifications for highly efficient synchronization, balancing flexibility and performance.

When NOT to use

Avoid event groups when you only need to signal a single event to one task; use task notifications instead for lower overhead. For passing data between tasks, use queues or message buffers rather than event groups. If you need more than 32 events, consider multiple event groups or other synchronization primitives.

Production Patterns

In real-world FreeRTOS applications, event groups are often used to signal multiple hardware events like sensor readiness or communication status to tasks. They are combined with timers and interrupts to build responsive, low-latency systems. Developers use event groups to implement state machines where tasks wait for combinations of events before transitioning states.

Connections

Bitmask Flags in Embedded Systems

Event groups use bitmask flags to represent multiple states in one variable, a common embedded pattern.

Understanding bitmask flags in hardware registers helps grasp how event groups efficiently track multiple events.

Semaphore Synchronization

Event groups build on the idea of semaphores but extend it to multiple simultaneous events.

Knowing semaphores clarifies event groups as a more flexible synchronization tool for complex conditions.

Traffic Light Control Systems

Event groups resemble how traffic lights coordinate multiple signals to control flow safely.

Seeing event groups like traffic signals helps understand how multiple conditions must be met before actions proceed.

Common Pitfalls

#1 Waiting on event bits without blocking causes CPU waste.

Wrong approach:

while((xEventGroupWaitBits(eventGroup, BIT_1, pdTRUE, pdFALSE, portMAX_DELAY) & BIT_1) == 0) { /* busy wait */ }

Correct approach:

xEventGroupWaitBits(eventGroup, BIT_1, pdTRUE, pdFALSE, portMAX_DELAY);

Root cause:

Misunderstanding that xEventGroupWaitBits blocks the task until bits are set, leading to unnecessary busy loops.

#2 Not clearing bits after waiting causes repeated triggers.

Wrong approach:

xEventGroupWaitBits(eventGroup, BIT_2, pdFALSE, pdTRUE, portMAX_DELAY); // pdFALSE means bits not cleared

Correct approach:

xEventGroupWaitBits(eventGroup, BIT_2, pdTRUE, pdTRUE, portMAX_DELAY); // pdTRUE clears bits automatically

Root cause:

Ignoring the auto-clear parameter causes bits to remain set, triggering tasks multiple times unexpectedly.

#3 Using event groups to pass data between tasks.

Wrong approach:

Setting bits to represent data values and trying to decode them in another task.

Correct approach:

Use FreeRTOS queues or message buffers to send actual data between tasks.

Root cause:

Confusing event groups as data carriers rather than synchronization flags.

Key Takeaways

Event groups let multiple tasks synchronize by setting and waiting on bits in a shared variable.

Tasks can wait for any or all bits to be set, with options to clear bits automatically after waiting.

Event groups are efficient for tracking multiple events but limited to 32 bits per group.

They internally use atomic operations and critical sections to prevent race conditions.

Choosing the right synchronization tool depends on the number of events, data needs, and system complexity.

Practice

1. What is the primary purpose of an event group in FreeRTOS for task synchronization?

easy

A. To allocate memory dynamically for tasks

B. To allow tasks to wait for multiple events using bits

C. To create queues for message passing

D. To manage task priorities automatically

Solution

1. Step 1: Understand event groups in FreeRTOS

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

2. Step 2: Identify the main use of event groups

   They help tasks synchronize by waiting on or setting bits representing events.

3. Final Answer:

   To allow tasks to wait for multiple events using bits -> Option B

4. Quick Check:

   Event groups = wait for multiple events [OK]

Hint: Event groups use bits to sync tasks, not memory or priorities [OK]

Common Mistakes:

• Confusing event groups with queues
• Thinking event groups manage memory
• Assuming event groups change task priorities

2. Which of the following is the correct function to wait for bits in an event group in FreeRTOS?

easy

A. xEventGroupClearBits()

B. xEventGroupSetBits()

C. xEventGroupWaitBits()

D. xEventGroupCreate()

Solution

1. Step 1: Recall FreeRTOS event group functions

   xEventGroupWaitBits() is used to wait for specific bits to be set.

2. Step 2: Differentiate from other functions

   xEventGroupSetBits() sets bits, ClearBits clears bits, Create creates the group.

3. Final Answer:

   xEventGroupWaitBits() -> Option C

4. Quick Check:

   Wait for bits = xEventGroupWaitBits() [OK]

Hint: Wait uses xEventGroupWaitBits(), set uses xEventGroupSetBits() [OK]

Common Mistakes:

• Using xEventGroupSetBits() to wait
• Confusing create with wait functions
• Mixing clear bits with wait bits

3. Given the following code snippet, what will be the value of bits after xEventGroupWaitBits() returns?

EventBits_t bits;
bits = xEventGroupWaitBits(eventGroup, BIT_0 | BIT_1, pdTRUE, pdFALSE, portMAX_DELAY);

Assume BIT_0 and BIT_1 are both set in eventGroup before the call.

medium

A. Only BIT_0 set

B. Only BIT_1 set

C. No bits set

D. Both BIT_0 and BIT_1 set

Solution

1. Step 1: Understand xEventGroupWaitBits parameters

   The function waits for BIT_0 or BIT_1 to be set, clears bits on exit (pdTRUE), and does not wait for all bits (pdFALSE).

2. Step 2: Analyze the bits set before call

   Both BIT_0 and BIT_1 are set, so the function returns with both bits set in the return value.

3. Final Answer:

   Both BIT_0 and BIT_1 set -> Option D

4. Quick Check:

   WaitBits returns bits set before clearing [OK]

Hint: WaitBits returns bits set before clearing them [OK]

Common Mistakes:

• Assuming only one bit is returned
• Ignoring bits cleared on exit
• Confusing wait for all bits with wait for any

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

EventGroupHandle_t eventGroup = xEventGroupCreate();

void Task1(void *pvParameters) {
    xEventGroupWaitBits(eventGroup, BIT_0, pdFALSE, pdTRUE, portMAX_DELAY);
    // Task code
}

void Task2(void *pvParameters) {
    xEventGroupSetBits(eventGroup, BIT_0);
}

medium

A. Not checking if eventGroup creation succeeded

B. Using portMAX_DELAY as wait time

C. Using pdFALSE for clearOnExit in xEventGroupWaitBits

D. Setting bits before event group creation

Solution

1. Step 1: Check event group creation

   xEventGroupCreate() can return NULL if creation fails; code does not check this.

2. Step 2: Verify other parameters

   Using pdFALSE for clearOnExit is valid; portMAX_DELAY is valid; bits are set after creation.

3. Final Answer:

   Not checking if eventGroup creation succeeded -> Option A

4. Quick Check:

   Always check event group creation success [OK]

Hint: Always verify event group creation returned non-NULL [OK]

Common Mistakes:

• Ignoring NULL return from xEventGroupCreate
• Misusing clearOnExit parameter
• Setting bits before creating event group

5. You want two tasks to synchronize so that Task A waits until Task B signals both BIT_0 and BIT_1. Which xEventGroupWaitBits() call correctly waits for both bits before continuing?

hard

A. xEventGroupWaitBits(eventGroup, BIT_0 | BIT_1, pdTRUE, pdTRUE, portMAX_DELAY);

B. xEventGroupWaitBits(eventGroup, BIT_0 & BIT_1, pdTRUE, pdTRUE, portMAX_DELAY);

C. xEventGroupWaitBits(eventGroup, BIT_0 | BIT_1, pdTRUE, pdFALSE, portMAX_DELAY);

D. xEventGroupWaitBits(eventGroup, BIT_0 & BIT_1, pdFALSE, pdFALSE, portMAX_DELAY);

Solution

1. Step 1: Understand wait for all bits parameter

   The fourth parameter (xWaitForAllBits) must be pdTRUE to wait for both bits together.

2. Step 2: Check bit mask and parameters

   Use BIT_0 | BIT_1 to specify both bits; pdTRUE for clearOnExit clears bits after wait.

3. Final Answer:

   xEventGroupWaitBits(eventGroup, BIT_0 | BIT_1, pdTRUE, pdTRUE, portMAX_DELAY); -> Option A

4. Quick Check:

   Wait for all bits = xEventGroupWaitBits with xWaitForAllBits = pdTRUE [OK]

Hint: Set xWaitForAllBits to pdTRUE to wait for all bits [OK]

Common Mistakes:

• Using bitwise AND (&) instead of OR (|) for bit mask
• Setting xWaitForAllBits to pdFALSE when waiting for all bits
• Confusing clearOnExit with wait for all bits