Task notifications in FreeRTOS are often described as lightweight. Which reason best explains why?
Think about how task notifications store data compared to other synchronization methods.
Task notifications use the task's own notification value, avoiding extra data structures like queues or semaphores. This makes them faster and uses less memory.
Consider the following FreeRTOS-like pseudocode where a task sends a notification using TaskNotifyGive and then receives it. What is the notification value received?
TaskNotifyGive(taskHandle); uint32_t value = 0; xTaskNotifyWait(0, 0xFFFFFFFF, &value, 0); print(value);
TaskNotifyGive increments the notification value by 1.
TaskNotifyGive increments the task's notification value by 1. So after sending, the value is 1, not 5.
Why does the following FreeRTOS code fail to unblock the waiting task?
uint32_t value; xTaskNotifyWait(0, 0xFFFFFFFF, &value, portMAX_DELAY); xTaskNotify(taskHandle, 0x01, eSetBits);
Consider the order of operations and how task notifications work.
The task waits for a notification before the notification is sent. If the notification is sent after the wait call, the task may miss it and remain blocked.
Which option shows the correct syntax to send a notification to a task that overwrites the notification value?
Check the order of parameters in the function call.
The correct syntax is xTaskNotify(taskHandle, value, action). Option C uses the correct order and action.
You need to signal a task frequently with minimal CPU and memory overhead. Which reason best justifies choosing task notifications over queues or semaphores?
Think about resource usage and simplicity of task notifications.
Task notifications are lightweight because they use the task's own notification value, avoiding extra kernel objects and memory, making them efficient for frequent signaling.