Deferred interrupt processing architecture in FreeRTOS - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to declare an interrupt service routine (ISR) in FreeRTOS.

FreeRTOS

void v[1]Handler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    // ISR code here
}

Drag options to blanks, or click blank then click option'

AADC

BTimer

CGPIO

DUART

Attempts:

3 left

💡 Hint

Common Mistakes

Using a generic name instead of a specific peripheral name.

Forgetting to declare the ISR with the correct signature.

The ISR name typically reflects the hardware interrupt source, such as UARTHandler for UART interrupts.

2fill in blank

medium

Complete the code to notify a task from an ISR using FreeRTOS API.

FreeRTOS

vTaskNotifyGiveFromISR(xTaskHandle, &[1]);

Drag options to blanks, or click blank then click option'

ApdTRUE

BxHigherPriorityTaskWoken

CpdFALSE

DNULL

Attempts:

3 left

💡 Hint

Common Mistakes

Passing pdTRUE or pdFALSE directly instead of the pointer variable.

Passing NULL which disables context switch notification.

The parameter is a pointer to a variable that indicates if a context switch is required.

3fill in blank

hard

Fix the error in the ISR to correctly perform deferred interrupt processing.

FreeRTOS

void vISR_Handler(void) {
    BaseType_t [1] = pdFALSE;
    // Clear interrupt flag
    vTaskNotifyGiveFromISR(xTaskHandle, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Drag options to blanks, or click blank then click option'

AxHigherPriorityTaskWoken

BxTaskWoken

CxInterruptFlag

DxNotifyFlag

Attempts:

3 left

💡 Hint

Common Mistakes

Using an undefined variable name.

Not calling portYIELD_FROM_ISR with the correct variable.

The variable xHigherPriorityTaskWoken must be declared and used to request a context switch.

4fill in blank

hard

Fill both blanks to create a deferred interrupt processing task that waits for notification.

FreeRTOS

void vDeferredTask(void *pvParameters) {
    for(;;) {
        ulTaskNotifyTake([1], [2]);
        // Process interrupt data here
    }
}

Drag options to blanks, or click blank then click option'

ApdTRUE

BportMAX_DELAY

CpdFALSE

D0

Attempts:

3 left

💡 Hint

Common Mistakes

Using pdFALSE instead of pdTRUE for clearing notification.

Using 0 instead of portMAX_DELAY causing no wait.

ulTaskNotifyTake uses pdTRUE to clear the notification count and portMAX_DELAY to wait indefinitely.

5fill in blank

hard

Fill all three blanks to implement a deferred interrupt processing system with ISR notification and task wait.

FreeRTOS

void vISR_Handler(void) {
    BaseType_t [1] = pdFALSE;
    vTaskNotifyGiveFromISR(xTaskHandle, &[2]);
    [3]YIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

void vDeferredTask(void *pvParameters) {
    for(;;) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        // Handle deferred processing
    }
}

Drag options to blanks, or click blank then click option'

AxHigherPriorityTaskWoken

BxTaskWoken

Dport

Attempts:

3 left

💡 Hint

Common Mistakes

Using different variable names inconsistently.

Omitting the 'port' prefix in portYIELD_FROM_ISR.

The variable xHigherPriorityTaskWoken is declared and used consistently. The macro portYIELD_FROM_ISR is called with the prefix 'port'.

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