Why event groups coordinate tasks in FreeRTOS - Visual Breakdown

Concept Flow - Why event groups coordinate tasks

Task A waits for event bits

↓

Task B sets event bits

↓

Event group updates bits

↓

Task A detects bits set

↓

Task A proceeds with work

↓

Event bits cleared or reset

↓

Tasks wait again or exit

Tasks wait for specific event bits; when another task sets these bits, the event group updates and notifies waiting tasks to proceed.

Execution Sample

FreeRTOS

EventGroupHandle_t eg = xEventGroupCreate();

// Task A waits for BIT_0
xEventGroupWaitBits(eg, BIT_0, pdTRUE, pdFALSE, portMAX_DELAY);

// Task B sets BIT_0
xEventGroupSetBits(eg, BIT_0);

Task A waits for a bit in the event group; Task B sets that bit to signal Task A to continue.

Execution Table

Step	Action	Event Bits Before	Event Bits After	Task State	Output/Result
1	Create event group	0b0000	0b0000	Both tasks ready	Event group created
2	Task A waits for BIT_0	0b0000	0b0000	Task A blocked, waiting	Waiting for BIT_0
3	Task B sets BIT_0	0b0000	0b0001	Task B running	BIT_0 set
4	Event group updates bits	0b0001	0b0001	Task A unblocked	Task A notified
5	Task A proceeds	0b0001	0b0000	Task A running	BIT_0 cleared after wait
6	Tasks continue or wait again	0b0000	0b0000	Tasks ready or blocked	Cycle repeats or ends

💡 Task A unblocks after BIT_0 is set; event bit cleared due to pdTRUE clear-on-exit flag

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	Final
Event Bits	0b0000	0b0000	0b0001	0b0001	0b0000	0b0000
Task A State	Ready	Blocked (waiting)	Blocked (waiting)	Ready (unblocked)	Running	Ready
Task B State	Ready	Ready	Running (sets bit)	Ready	Ready	Ready

Key Moments - 3 Insights

Why does Task A block at step 2 even though the event group exists?

Because the event bit BIT_0 is not set yet (0b0000), Task A must wait until another task sets it, as shown in execution_table row 2.

Why does the event bit clear after Task A proceeds at step 5?

The wait function was called with pdTRUE to clear bits on exit, so after Task A detects BIT_0, the bit is cleared automatically (see execution_table row 5).

How does Task B's action affect Task A's state?

When Task B sets BIT_0 (step 3), the event group updates bits and unblocks Task A (step 4), allowing Task A to continue (execution_table rows 3 and 4).

Visual Quiz - 3 Questions

Look at the execution table, what is the value of Event Bits after Task B sets BIT_0?

A 0b0000

B 0b0001

C 0b0010

D 0b1111

💡 Hint

Check execution_table row 3 under 'Event Bits After'

At which step does Task A unblock and proceed?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at execution_table rows 4 and 5 for Task A state changes

If pdTRUE was changed to pdFALSE in Task A's wait call, what would happen to the event bits after Task A proceeds?

A Event bits would remain set

B Event bits would clear immediately

C Event bits would toggle randomly

D Event bits would reset to 0b1111

💡 Hint

Refer to key_moments about bit clearing behavior and execution_table row 5

Concept Snapshot

Event groups let tasks wait for one or more bits to be set.
Tasks block until bits they wait for are set by other tasks.
When bits are set, waiting tasks unblock and proceed.
Bits can be cleared automatically after wait or left set.
This coordination helps tasks synchronize easily.

Full Transcript

In FreeRTOS, event groups help tasks coordinate by waiting for bits to be set. Task A waits for a specific bit (BIT_0) to be set in the event group. Initially, the bit is not set, so Task A blocks and waits. Task B then sets BIT_0, updating the event group bits. This change unblocks Task A, which detects the bit set and proceeds with its work. If the wait call uses the clear-on-exit flag, the bit is cleared after Task A proceeds. This mechanism allows tasks to synchronize their actions by signaling events through bits in the event group.

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