Event-driven architecture in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Event Group Bits Setting and Clearing

What is the output of this FreeRTOS code snippet that uses event groups to set and clear bits?

FreeRTOS

EventGroupHandle_t eventGroup = xEventGroupCreate();

xEventGroupSetBits(eventGroup, (1 << 0));
xEventGroupSetBits(eventGroup, (1 << 1));

EventBits_t bits = xEventGroupClearBits(eventGroup, (1 << 0));

printf("Bits before clear: 0x%X\n", bits);
printf("Bits after clear: 0x%X\n", xEventGroupGetBits(eventGroup));

A

Bits before clear: 0x2
Bits after clear: 0x1

B

Bits before clear: 0x1
Bits after clear: 0x3

C

Bits before clear: 0x3
Bits after clear: 0x2

D

Bits before clear: 0x0
Bits after clear: 0x0

💡 Hint

Remember that xEventGroupClearBits returns the bits before clearing.

The code sets bits 0 and 1 (0x1 and 0x2), so before clearing, bits are 0x3. Clearing bit 0 removes 0x1, leaving 0x2.

🧠 Conceptual

intermediate

Understanding Event-Driven Task Notification

In FreeRTOS, which statement best describes the behavior of task notifications used as lightweight event flags?

A Task notifications require a separate queue to send data between tasks.

B Task notifications can only be used to unblock a task and cannot carry data.

C Task notifications automatically queue multiple events if sent rapidly.

D Task notifications can be used both to unblock a task and to send 32-bit data atomically.

💡 Hint

Think about how task notifications combine signaling and data transfer.

Task notifications in FreeRTOS are lightweight and can both unblock a task and carry a 32-bit value atomically without extra queues.

🔧 Debug

advanced

Debugging Event Group Wait Timeout

A task waits for bits 0x01 and 0x02 using xEventGroupWaitBits with the wait option to clear bits on exit. The task never proceeds even though another task sets bit 0x01. What is the most likely cause?

FreeRTOS

xEventGroupWaitBits(eventGroup, 0x03, pdTRUE, pdTRUE, portMAX_DELAY);

A The wait condition requires both bits 0x01 and 0x02 to be set, but only 0x01 is set.

B The bits are cleared before the wait, causing the function to return immediately.

C The event group handle is NULL, so the wait never succeeds.

D The task priority is too low to run after the bits are set.

💡 Hint

Check the 'wait for all bits' parameter and which bits are set.

The function waits for both bits 0x01 and 0x02 (0x03) to be set. If only 0x01 is set, the wait never completes.

📝 Syntax

advanced

Identify the Syntax Error in Event Group Creation

Which option contains the correct syntax to create an event group in FreeRTOS?

A EventGroupHandle_t eg = xEventGroupCreate();

B EventGroupHandle_t eg = xEventGroupCreate;

C EventGroupHandle_t eg = xEventGroupCreate[];

D EventGroupHandle_t eg = xEventGroupCreate();;

💡 Hint

Remember that xEventGroupCreate is a function that returns a handle.

Option A correctly calls the function with parentheses. Option A misses parentheses, C uses invalid brackets, A has an extra semicolon but compiles (though stylistically odd).

🚀 Application

expert

Designing an Event-Driven Task Synchronization

You want to synchronize three tasks so that each waits until all three have reached a certain point before continuing. Which FreeRTOS event-driven mechanism is best suited for this?

A Use a counting semaphore initialized to zero and each task gives once, then all tasks take once.

B Use an event group where each task sets its own bit and all tasks wait for all bits to be set.

C Use a binary semaphore that each task takes and gives to signal readiness.

D Use task notifications with each task notifying the others directly.

💡 Hint

Think about a mechanism that can track multiple flags and wait for all.

An event group allows each task to set a unique bit and wait until all bits are set, effectively synchronizing all tasks at a barrier.

Practice

1. What is the main benefit of using event-driven architecture in FreeRTOS?

easy

A. It makes the program run all tasks continuously without waiting.

B. It requires more CPU power to check all events constantly.

C. The program reacts only when an event occurs, saving CPU time.

D. It disables multitasking to focus on one task at a time.

Solution

1. Step 1: Understand event-driven architecture basics

   Event-driven architecture means the program waits and reacts only when events happen, not running tasks all the time.

2. Step 2: Connect to FreeRTOS event groups

   FreeRTOS event groups let tasks wait efficiently for events, saving CPU time by not running unnecessarily.

3. Final Answer:

   The program reacts only when an event occurs, saving CPU time. -> Option C

4. Quick Check:

   Event-driven = React on event, save CPU [OK]

Hint: Event-driven means react only on events, not always running [OK]

Common Mistakes:

• Thinking event-driven runs all tasks continuously
• Believing it uses more CPU by checking constantly
• Confusing event-driven with disabling multitasking

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

easy

A. EventGroup xEventGroup = xCreateEventGroup();

B. EventGroupHandle_t xEventGroup = xEventGroupCreate();

C. xEventGroup = EventGroupCreate();

D. EventGroupHandle_t xEventGroup = createEventGroup();

Solution

1. Step 1: Recall FreeRTOS event group creation syntax

   The official FreeRTOS function to create an event group is xEventGroupCreate(), returning EventGroupHandle_t.

2. Step 2: Match the correct syntax

   EventGroupHandle_t xEventGroup = xEventGroupCreate(); uses the correct function name and type: EventGroupHandle_t xEventGroup = xEventGroupCreate();

3. Final Answer:

   EventGroupHandle_t xEventGroup = xEventGroupCreate(); -> Option B

4. Quick Check:

   Correct function and type = EventGroupHandle_t xEventGroup = xEventGroupCreate(); [OK]

Hint: FreeRTOS event groups use xEventGroupCreate() function [OK]

Common Mistakes:

• Using wrong function names like createEventGroup()
• Missing the correct handle type EventGroupHandle_t
• Incorrect capitalization or function syntax

3. Given the code snippet:
<pre>EventGroupHandle_t xEventGroup = xEventGroupCreate(); // Task A waits for bit 0 and bit 1 EventBits_t uxBits = xEventGroupWaitBits(xEventGroup, (1 << 0) | (1 << 1), pdTRUE, pdTRUE, portMAX_DELAY); // Task B sets bit 0 xEventGroupSetBits(xEventGroup, (1 << 0)); // Task C sets bit 1 xEventGroupSetBits(xEventGroup, (1 << 1)); // What is the value of uxBits after Task A unblocks?

medium

A. 0x03 (both bits 0 and 1 set)

B. 0x01 (only bit 0 set)

C. 0x02 (only bit 1 set)

D. 0x00 (no bits set)

Solution

1. Step 1: Understand xEventGroupWaitBits parameters

   Task A waits for bits 0 and 1 together (bitmask 0x03), clears bits on exit (pdTRUE), waits for all bits (pdTRUE), and waits indefinitely.

2. Step 2: Analyze bit setting by Task B and Task C

   Task B sets bit 0 (0x01), Task C sets bit 1 (0x02). When both bits are set, Task A unblocks and uxBits contains both bits set (0x03).

3. Final Answer:

   0x03 (both bits 0 and 1 set) -> Option A

4. Quick Check:

   Wait for bits 0 & 1 set = 0x03 [OK]

Hint: WaitBits returns all requested bits set when unblocked [OK]

Common Mistakes:

• Assuming only one bit is set when unblocked
• Ignoring that wait is for all bits (pdTRUE)
• Confusing bit masks with decimal values

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

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

medium

A. xEventGroupSetBits requires a pointer, not a handle.

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

C. Event groups cannot set bits directly.

D. xEventGroup is not created before use.

Solution

1. Step 1: Check event group initialization

   xEventGroup is declared but never created with xEventGroupCreate(), so it is uninitialized (likely NULL).

2. Step 2: Understand consequences of uninitialized handle

   Calling xEventGroupSetBits with an uninitialized handle causes undefined behavior or crash.

3. Final Answer:

   xEventGroup is not created before use. -> Option D

4. Quick Check:

   Create event group before use [OK]

Hint: Always create event group before setting bits [OK]

Common Mistakes:

• Forgetting to call xEventGroupCreate()
• Thinking bit mask is invalid
• Misunderstanding handle vs pointer usage

5. You want a FreeRTOS task to wait for either bit 2 or bit 3 to be set in an event group, but not both. Which call correctly implements this behavior?

hard

A. xEventGroupWaitBits(xEventGroup, (1 << 2) | (1 << 3), pdTRUE, pdFALSE, portMAX_DELAY);

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

C. xEventGroupWaitBits(xEventGroup, (1 << 2) & (1 << 3), pdTRUE, pdFALSE, portMAX_DELAY);

D. xEventGroupWaitBits(xEventGroup, (1 << 2) | (1 << 3), pdFALSE, pdTRUE, portMAX_DELAY);

Solution

1. Step 1: Understand the parameters for xEventGroupWaitBits

   The third parameter clears bits on exit (pdTRUE), the fourth parameter controls if waiting for all bits (pdTRUE) or any bit (pdFALSE).

2. Step 2: Match requirement to wait for either bit 2 or bit 3, but not both

   Waiting for any bit means pdFALSE for the fourth parameter. Using bitmask (1 << 2) | (1 << 3) waits for either bit 2 or bit 3.

3. Final Answer:

   xEventGroupWaitBits(xEventGroup, (1 << 2) | (1 << 3), pdTRUE, pdFALSE, portMAX_DELAY); -> Option A

4. Quick Check:

   Wait for any bit = pdFALSE, bitmask ORed = xEventGroupWaitBits(xEventGroup, (1 << 2) | (1 << 3), pdTRUE, pdFALSE, portMAX_DELAY); [OK]

Hint: Use pdFALSE to wait for any bit, not all bits [OK]

Common Mistakes:

• Using pdTRUE to wait for all bits instead of any
• Using bitwise AND instead of OR for bitmask
• Not clearing bits on exit when needed