ISR-to-task notification pattern in FreeRTOS - Step-by-Step Execution

Concept Flow - ISR-to-task notification pattern

Interrupt Occurs

↓

ISR Executes

↓

Send Notification to Task

↓

Task Receives Notification

↓

Task Processes Event

↓

Task Waits for Next Notification

When an interrupt happens, the ISR sends a notification to a task, which then wakes up and processes the event.

Execution Sample

FreeRTOS

void ISR_Handler() {
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
  vTaskNotifyGiveFromISR(taskHandle, &xHigherPriorityTaskWoken);
  portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void TaskFunction(void *params) {
  for(;;) {
    ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
    // Process event
  }
}

ISR sends notification to a task; task waits for notification and processes event when notified.

Execution Table

Step	Context	Action	Notification State	Task State	Output/Result
1	Interrupt Occurs	ISR_Handler starts	Notification = 0	Task blocked waiting	No output
2	ISR	vTaskNotifyGiveFromISR called	Notification incremented to 1	Task still blocked	No output
3	ISR	portYIELD_FROM_ISR checks xHigherPriorityTaskWoken	Notification = 1	Task unblocked if higher priority	Context switch if needed
4	Task	ulTaskNotifyTake called	Notification decremented to 0	Task running	Task wakes and processes event
5	Task	Task processes event	Notification = 0	Task running	Event handled
6	Task	Task loops back to wait	Notification = 0	Task blocked waiting	Waiting for next notification
7	No new interrupt	No notification sent	Notification = 0	Task blocked	No output

💡 Execution waits indefinitely at ulTaskNotifyTake until next ISR notification.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6
Notification Count	0	1	0	0
Task State	Blocked	Blocked	Running	Blocked

Key Moments - 3 Insights

Why does the task unblock after the ISR sends a notification?

Because in step 3, portYIELD_FROM_ISR triggers a context switch if the task has higher priority and a notification was sent, unblocking the task as shown in the execution_table.

What happens if the task does not call ulTaskNotifyTake after notification?

The notification count remains at 1 (step 2), but the task stays blocked until it calls ulTaskNotifyTake to consume the notification, as seen in steps 2 and 4.

Can notifications be lost if multiple interrupts occur before the task processes them?

No, notifications accumulate as counts (step 2 increments notification), so multiple ISR calls increase the notification count until the task processes them.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the notification count after vTaskNotifyGiveFromISR is called?

A 1

B 0

C 2

D Undefined

💡 Hint

Check the 'Notification State' column at step 2 in the execution_table.

At which step does the task change from blocked to running?

A Step 1

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the 'Task State' column in the execution_table to see when it changes to running.

If the ISR is called twice before the task runs, how would the notification count change after step 2?

A Notification count would be 1

B Notification count would be 2

C Notification count would be 0

D Notification count would reset to 0

💡 Hint

Refer to the variable_tracker and key moment about notification accumulation.

Concept Snapshot

ISR-to-task notification pattern in FreeRTOS:
- ISR sends notification using vTaskNotifyGiveFromISR.
- Task waits with ulTaskNotifyTake.
- Notification increments unblock the task.
- portYIELD_FROM_ISR triggers context switch if needed.
- Notifications accumulate if multiple ISRs occur before task runs.

Full Transcript

This visual execution trace shows how an interrupt service routine (ISR) communicates with a FreeRTOS task using the ISR-to-task notification pattern. When an interrupt occurs, the ISR runs and calls vTaskNotifyGiveFromISR to send a notification to the task. This increments the notification count. If the task has higher priority, portYIELD_FROM_ISR triggers a context switch to unblock the task. The task, which waits on ulTaskNotifyTake, then wakes up, consumes the notification (decrementing the count), and processes the event. After processing, the task waits again for the next notification. Notifications accumulate if multiple interrupts happen before the task processes them, ensuring no events are lost. The execution table and variable tracker show step-by-step changes in notification count and task state, helping beginners understand the flow and synchronization between ISR and task.