Deferred interrupt processing architecture in FreeRTOS - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is deferred interrupt processing in FreeRTOS?

Deferred interrupt processing is a method where the interrupt service routine (ISR) does minimal work and defers the main processing to a task or a lower priority context to keep ISRs short and efficient.

beginner

Why should interrupt service routines (ISRs) be kept short in FreeRTOS?

ISRs should be short to minimize the time interrupts are disabled, reduce latency for other interrupts, and avoid blocking the scheduler, ensuring the system remains responsive.

intermediate

Name two common mechanisms used in FreeRTOS for deferred interrupt processing.

1. Using queues to send data from ISR to a task.
2. Using task notifications to signal a task from an ISR.

intermediate

How does a queue help in deferred interrupt processing in FreeRTOS?

The ISR places data or events into a queue quickly, then a task reads from the queue and performs the heavier processing outside the ISR context.

intermediate

What is the role of task notifications in deferred interrupt processing?

Task notifications allow an ISR to signal a specific task that work is ready, waking it up to handle processing, which keeps ISRs short and efficient.

What is the main goal of deferred interrupt processing in FreeRTOS?

A To keep ISRs short and defer heavy work to tasks

B To run all processing inside the ISR

C To disable all interrupts during processing

D To avoid using tasks for interrupt handling

Deferred interrupt processing keeps ISRs short by deferring heavy work to tasks, improving system responsiveness.

Which FreeRTOS feature is commonly used to pass data from an ISR to a task?

A Event groups

B Queues

C Semaphores

D Mutexes

Queues are used to safely pass data from ISRs to tasks in FreeRTOS.

What should an ISR avoid doing to maintain system responsiveness?

A Performing long or blocking operations

B Signaling a task

C Using task notifications

D Posting to a queue

ISRs should avoid long or blocking operations to keep the system responsive.

Which of the following is NOT a benefit of deferred interrupt processing?

A Reduced interrupt latency

B Shorter ISR execution time

C Increased ISR complexity

D Better system responsiveness

Deferred interrupt processing reduces ISR complexity by moving heavy work to tasks.

How does a task notification differ from a queue in deferred interrupt processing?

A Neither can be used in ISRs

B Task notifications pass data, queues only signal

C Both are identical in usage

D Task notifications signal a task without passing data, queues pass data

Task notifications are lightweight signals to wake a task, while queues can pass data from ISR to task.

Explain how deferred interrupt processing improves system performance in FreeRTOS.

Think about what happens inside the ISR versus the task.

Describe two methods FreeRTOS provides to implement deferred interrupt processing and how they work.

Focus on communication between ISR and tasks.

Practice

1. What is the main purpose of deferred interrupt processing in FreeRTOS?

easy

A. To disable all interrupts during task execution

B. To execute all interrupt code inside the ISR for speed

C. To split interrupt handling between a fast ISR and a slower task

D. To avoid using queues or notifications in interrupt handling

Solution

1. Step 1: Understand ISR limitations

   ISRs should be short to keep system responsive and avoid blocking other interrupts.

2. Step 2: Role of deferred processing

   Deferred processing moves longer work to a task, improving system reliability and responsiveness.

3. Final Answer:

   To split interrupt handling between a fast ISR and a slower task -> Option C

4. Quick Check:

   Deferred interrupt processing = splitting work [OK]

Hint: Remember: ISR is fast, task does the heavy work [OK]

Common Mistakes:

• Thinking all work should be done inside ISR
• Believing interrupts are disabled during task execution
• Ignoring the use of task notifications or queues

2. Which of the following is the correct way to notify a task from an ISR in FreeRTOS?

easy

A. xTaskNotifyGiveFromISR(taskHandle, &higherPriorityTaskWoken);

B. xTaskNotifyGive(taskHandle);

C. vTaskDelay(10);

D. xQueueSend(queueHandle, &data, portMAX_DELAY);

Solution

1. Step 1: Identify ISR-safe notification function

   Only functions ending with 'FromISR' are safe to call inside ISRs.

2. Step 2: Check options

   xTaskNotifyGiveFromISR is designed for ISR context; others are not ISR-safe or unrelated.

3. Final Answer:

   xTaskNotifyGiveFromISR(taskHandle, &higherPriorityTaskWoken); -> Option A

4. Quick Check:

   ISR notification uses FromISR functions [OK]

Hint: Use 'FromISR' functions inside ISRs only [OK]

Common Mistakes:

• Using normal task notification functions inside ISR
• Calling blocking functions like vTaskDelay in ISR
• Using queue send with infinite block time inside ISR

3. Given the following code snippet, what will be the output?

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

void TaskFunction(void *pvParameters) {
    for(;;) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        printf("Task notified\n");
    }
}

medium

A. Task notified printed only once

B. No output because task is never notified

C. Compilation error due to missing parameters

D. Task notified printed each time ISR runs

Solution

1. Step 1: Analyze ISR notification

   ISR calls xTaskNotifyGiveFromISR which increments the task's notification count and may cause context switch.

2. Step 2: Analyze task behavior

   Task blocks on ulTaskNotifyTake until notified, then prints "Task notified" and loops back to wait again.

3. Final Answer:

   Task notified printed each time ISR runs -> Option D

4. Quick Check:

   ISR notifies task -> task prints [OK]

Hint: ISR notification wakes task repeatedly [OK]

Common Mistakes:

• Assuming task never wakes up
• Confusing notification count with binary flag
• Thinking task prints only once

4. Identify the error in this deferred interrupt processing code snippet:

void ISR_Handler() {
    xQueueSend(queueHandle, &data, portMAX_DELAY);
}

void TaskFunction(void *pvParameters) {
    for(;;) {
        if(xQueueReceive(queueHandle, &receivedData, portMAX_DELAY) == pdPASS) {
            process(receivedData);
        }
    }
}

medium

A. xQueueReceive should be called from ISR

B. Using portMAX_DELAY in ISR causes a blocking call

C. ISR should not send data to queue

D. Task should not block on queue receive

Solution

1. Step 1: Check ISR queue send parameters

   portMAX_DELAY causes blocking; ISRs must never block or wait.

2. Step 2: Correct usage in ISR

   Use xQueueSendFromISR with zero block time to avoid blocking in ISR.

3. Final Answer:

   Using portMAX_DELAY in ISR causes a blocking call -> Option B

4. Quick Check:

   ISRs must not block = no portMAX_DELAY in ISR [OK]

Hint: Never block inside ISR; use FromISR functions with zero wait [OK]

Common Mistakes:

• Using blocking calls inside ISR
• Calling task functions from ISR
• Confusing ISR and task context functions

5. You want to design a deferred interrupt processing system where multiple ISRs notify a single task to process different events. Which approach best ensures the task processes all events without missing any notifications?

hard

A. Use a queue to send event data from each ISR to the task

B. Use xTaskNotifyGiveFromISR from each ISR without data

C. Use global flags set by ISRs and polled by the task

D. Disable interrupts while the task processes events

Solution

1. Step 1: Understand notification limitations

   xTaskNotifyGiveFromISR increments a count but cannot carry event data, risking lost info if multiple events occur quickly.

2. Step 2: Use queue for event data

   Queues can hold multiple event messages safely, ensuring the task processes all events without loss.

3. Final Answer:

   Use a queue to send event data from each ISR to the task -> Option A

4. Quick Check:

   Queues hold multiple events safely [OK]

Hint: Use queues to handle multiple event data safely [OK]

Common Mistakes:

• Relying on notifications without event data
• Using global flags causing race conditions
• Disabling interrupts too long hurting responsiveness