Deferred interrupt processing architecture in FreeRTOS - Step-by-Step Execution

Concept Flow - Deferred interrupt processing architecture

Interrupt Occurs

↓

ISR Starts

↓

Quick ISR Work

↓

Schedule Deferred Handler

↓

ISR Ends

↓

Deferred Handler Runs in Task Context

↓

Complete Processing

When an interrupt happens, the ISR does only quick work and schedules a deferred handler to finish the job later in normal task context.

Execution Sample

FreeRTOS

void ISR_Handler() {
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
  xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);
  portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void DeferredTask(void *pvParameters) {
  for(;;) {
    xSemaphoreTake(xSemaphore, portMAX_DELAY);
    // Process deferred work
  }
}

ISR quickly gives a semaphore to unblock a task that does the deferred processing.

Execution Table

Step	Action	ISR Work	Deferred Handler Work	Context Switch
1	Interrupt occurs	Start ISR	No	No
2	ISR gives semaphore	Give semaphore	No	No
3	ISR ends	Exit ISR	No	Possible if higher priority task unblocked
4	Deferred task unblocked	No	Unblocked, waiting for semaphore	No
5	Deferred task takes semaphore	No	Take semaphore	No
6	Deferred task processes work	No	Process deferred work	No
7	Deferred task loops back	No	Wait for next semaphore	No

💡 ISR finishes quickly; deferred task handles full processing after semaphore is given.

Variable Tracker

Variable	Start	After ISR Step 2	After Deferred Task Step 5	Final
xHigherPriorityTaskWoken	pdFALSE	pdTRUE if task unblocked	N/A	N/A
xSemaphore	Empty	Given by ISR	Taken by deferred task	Empty after take

Key Moments - 3 Insights

Why does the ISR only give a semaphore and not do the full processing?

The ISR must be very fast to avoid blocking other interrupts. The full processing is deferred to a task context, as shown in execution_table rows 2 and 6.

How does the deferred task know when to run?

The deferred task waits on a semaphore. When the ISR gives the semaphore (row 2), the task unblocks and runs (rows 5 and 6).

What triggers a context switch after the ISR?

If the ISR unblocks a higher priority task (xHigherPriorityTaskWoken becomes true), portYIELD_FROM_ISR triggers a context switch (row 3).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the ISR give the semaphore?

A Step 4

B Step 2

C Step 5

D Step 6

💡 Hint

Check the 'ISR Work' column for when the semaphore is given.

According to variable_tracker, what is the state of xSemaphore after the deferred task takes it?

A Given by ISR

B Taken by deferred task

C Empty

D pdTRUE

💡 Hint

Look at the 'Final' column for xSemaphore in variable_tracker.

If the ISR did all processing inside itself, what would likely happen?

A Other interrupts might be delayed

B ISR would be faster

C Deferred task would run sooner

D Semaphore would not be needed

💡 Hint

Refer to key_moments about ISR speed and deferred processing.

Concept Snapshot

Deferred interrupt processing means:
- ISR does minimal, quick work
- ISR signals a task (e.g., via semaphore)
- Deferred task does heavy processing
- Keeps ISR fast and responsive
- Uses FreeRTOS primitives like xSemaphoreGiveFromISR
- Context switch may happen if higher priority task unblocked

Full Transcript

Deferred interrupt processing architecture in FreeRTOS means that when an interrupt occurs, the interrupt service routine (ISR) does only the minimal necessary work quickly, such as giving a semaphore. This semaphore unblocks a deferred task that runs in normal task context to complete the heavier processing. This approach keeps the ISR short and responsive, avoiding delays to other interrupts. The ISR uses functions like xSemaphoreGiveFromISR and may trigger a context switch if a higher priority task is unblocked. The deferred task waits on the semaphore and processes the work when unblocked. This design improves system responsiveness and reliability.