Deferred interrupt processing pattern in FreeRTOS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of deferred interrupt processing with task notification

Consider a FreeRTOS system where an ISR notifies a task to process data later. What will be the output when the task receives the notification?

FreeRTOS

#include "FreeRTOS.h"
#include "task.h"
#include <stdio.h>

TaskHandle_t xTaskHandle = NULL;

void vISR_Handler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    vTaskNotifyGiveFromISR(xTaskHandle, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void vTaskFunction(void *pvParameters) {
    for (;;) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        printf("Task processed deferred interrupt\n");
    }
}

int main() {
    xTaskCreate(vTaskFunction, "Task", 1000, NULL, 1, &xTaskHandle);
    // Simulate ISR call
    vISR_Handler();
    // Normally scheduler would run, here we simulate one iteration
    vTaskFunction(NULL);
    return 0;
}

A Task processed deferred interrupt\nTask processed deferred interrupt

B No output

C Task processed deferred interrupt

D Compilation error

💡 Hint

Think about how task notifications unblock the task exactly once per notification.

The ISR sends a notification to the task, which unblocks the task once. The task then prints the message once. The simulated call to vTaskFunction after ISR processes the notification and prints the output once.

🧠 Conceptual

intermediate

Why use deferred interrupt processing in FreeRTOS?

Which of the following best explains the main reason to use deferred interrupt processing in FreeRTOS?

A To minimize the time spent inside the ISR and avoid blocking operations there

B To allow ISRs to run longer and perform complex calculations

C To eliminate the need for tasks in the system

D To increase the priority of all interrupts automatically

💡 Hint

Think about what is safe and recommended inside an ISR.

Deferred interrupt processing moves heavy or blocking work out of the ISR into a task, keeping ISRs short and fast, which is critical for system responsiveness.

🔧 Debug

advanced

Identify the error in deferred interrupt processing code

What error will occur in this FreeRTOS ISR code snippet? void vISR_Handler(void) { vTaskNotifyGive(xTaskHandle); } Assume xTaskHandle is a valid task handle.

A Potential race condition because vTaskNotifyGive is called outside ISR context

B Compilation error due to missing parameters

C No error, code works correctly

D Runtime error because vTaskNotifyGiveFromISR should be used inside ISR

💡 Hint

Consider which FreeRTOS API functions are safe to call inside an ISR.

Inside an ISR, the FromISR version of API functions must be used. Using vTaskNotifyGive inside ISR is unsafe and can cause runtime errors.

📝 Syntax

advanced

Correct syntax for deferred interrupt processing with queue

Which option shows the correct way to send data from an ISR to a task using a FreeRTOS queue?

A xQueueSendFromISR(queueHandle, &data, &xHigherPriorityTaskWoken);

B xQueueSend(queueHandle, &data, 0);

C xQueueSend(queueHandle, &data, &xHigherPriorityTaskWoken);

D xQueueSendFromISR(queueHandle, &data, NULL);

💡 Hint

Inside ISR, use the FromISR version and handle the task wake flag.

Inside an ISR, xQueueSendFromISR must be used with a pointer to a BaseType_t variable to indicate if a context switch is needed.

🚀 Application

expert

Design deferred interrupt processing for multiple interrupt sources

You have three different hardware interrupts that must notify a single task to process events. Which design pattern best ensures all events are processed without losing notifications?

A Use task notifications with ulTaskNotifyTake called once per ISR event

B Use a counting semaphore given by each ISR and taken by the task to track multiple events

C Use a binary semaphore given by each ISR to unblock the task

D Use global flags set by ISRs and polled by the task without synchronization

💡 Hint

Consider how to count multiple events from different ISRs reliably.

A counting semaphore allows multiple ISR events to be counted and ensures the task processes each event without missing any. Binary semaphores or single notifications can miss events if multiple occur before the task runs.

Practice

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

easy

A. To move heavy processing from the ISR to a task for better system responsiveness

B. To execute all interrupt code inside the ISR for faster response

C. To disable all interrupts during task execution

D. To avoid using semaphores or queues in interrupt handling

Solution

1. Step 1: Understand ISR limitations

   Interrupt Service Routines (ISRs) should be short to keep system responsive.

2. Step 2: Role of deferred processing

   Heavy or time-consuming work is moved to a task, triggered by ISR using semaphores or queues.

3. Final Answer:

   To move heavy processing from the ISR to a task for better system responsiveness -> Option A

4. Quick Check:

   Deferred processing = move work out of ISR [OK]

Hint: Heavy work belongs in tasks, not ISRs [OK]

Common Mistakes:

• Thinking all work should be done inside ISR
• Believing interrupts should be disabled during tasks
• Ignoring use of semaphores or queues

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

easy

A. vTaskDelay()

B. xSemaphoreGive()

C. xSemaphoreGiveFromISR()

D. xQueueSend()

Solution

1. Step 1: Identify ISR-safe functions

   Functions called from ISRs must be ISR-safe variants, like xSemaphoreGiveFromISR().

2. Step 2: Compare options

   xSemaphoreGive() is for tasks, not ISRs; vTaskDelay() is a task delay; xQueueSend() is not ISR-safe.

3. Final Answer:

   xSemaphoreGiveFromISR() -> Option C

4. Quick Check:

   Use FromISR functions inside ISRs [OK]

Hint: Use FromISR suffix functions inside ISRs [OK]

Common Mistakes:

• Using task-only functions inside ISR
• Calling blocking functions in ISR
• Not using FromISR variants

3. Consider this snippet inside an ISR in FreeRTOS:

BaseType_t xHigherPriorityTaskWoken = pdFALSE;
xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

What is the purpose of portYIELD_FROM_ISR() here?

medium

A. To reset the semaphore count

B. To request a context switch if a higher priority task was woken

C. To delay the ISR until the task runs

D. To disable interrupts after giving the semaphore

Solution

1. Step 1: Understand xHigherPriorityTaskWoken

   This flag indicates if giving the semaphore woke a higher priority task.

2. Step 2: Role of portYIELD_FROM_ISR()

   If the flag is true, portYIELD_FROM_ISR() requests a context switch to run the higher priority task immediately.

3. Final Answer:

   To request a context switch if a higher priority task was woken -> Option B

4. Quick Check:

   portYIELD_FROM_ISR triggers context switch [OK]

Hint: portYIELD_FROM_ISR triggers immediate task switch [OK]

Common Mistakes:

• Thinking it disables interrupts
• Assuming it delays ISR execution
• Confusing it with semaphore reset

4. You wrote this ISR code to notify a task:

void ISR_Handler(void) {
    xSemaphoreGive(xSemaphore);
}

Why might this cause problems in FreeRTOS?

medium

A. xSemaphoreGive() is not safe to call from an ISR

B. The semaphore is given twice accidentally

C. The ISR does not clear the interrupt flag

D. The task will never unblock

Solution

1. Step 1: Check function usage in ISR

   xSemaphoreGive() is a task-level function and is not safe to call inside an ISR.

2. Step 2: Correct function to use

   Inside ISR, xSemaphoreGiveFromISR() must be used to safely notify the task.

3. Final Answer:

   xSemaphoreGive() is not safe to call from an ISR -> Option A

4. Quick Check:

   Use FromISR functions in ISRs [OK]

Hint: Never call task functions inside ISR, use FromISR versions [OK]

Common Mistakes:

• Calling task functions inside ISR
• Forgetting to clear interrupt flags
• Assuming semaphore gives always unblock tasks

5. You want to implement deferred interrupt processing where an ISR signals a task to process sensor data. Which sequence correctly follows FreeRTOS best practices?

hard

A. Task polls sensor data continuously, ISR disables interrupts

B. ISR processes sensor data directly, then calls vTaskDelay()

C. ISR sends data via xQueueSend(), task never blocks

D. ISR calls xSemaphoreGiveFromISR(), then task waits on semaphore and processes data

Solution

1. Step 1: ISR role in deferred processing

   ISR should be short and only notify the task using xSemaphoreGiveFromISR().

2. Step 2: Task role in processing

   The task waits on the semaphore and processes sensor data when notified.

3. Final Answer:

   ISR calls xSemaphoreGiveFromISR(), then task waits on semaphore and processes data -> Option D

4. Quick Check:

   ISR signals, task processes data [OK]

Hint: ISR signals; task does heavy work [OK]

Common Mistakes:

• Doing heavy work inside ISR
• Using blocking calls inside ISR
• Not synchronizing task and ISR properly