Deferred interrupt processing architecture in FreeRTOS - Mini Project: Build & Apply

Deferred Interrupt Processing with FreeRTOS

📖 Scenario: You are building a simple embedded system using FreeRTOS. The system reads data from a sensor that triggers an interrupt when new data is ready. To keep the interrupt fast and responsive, you will use deferred interrupt processing by handling the heavy work in a FreeRTOS task instead of inside the interrupt.

🎯 Goal: Create a FreeRTOS program that uses an interrupt service routine (ISR) to notify a task to process sensor data. The ISR will only send a notification, and the task will do the actual data processing.

📋 What You'll Learn

Create a global variable sensor_data_ready initialized to 0

Create a FreeRTOS task called SensorTask that waits for a notification

Create an ISR function called SensorISR_Handler that sets sensor_data_ready to 1 and notifies SensorTask

In SensorTask, clear sensor_data_ready and print "Processing sensor data..." when notified

💡 Why This Matters

🌍 Real World

Deferred interrupt processing is used in embedded systems to keep interrupts fast and responsive by moving heavy work to tasks.

💼 Career

Understanding this architecture is important for embedded software engineers working with real-time operating systems like FreeRTOS.

1

Create the initial data setup

Create a global variable called sensor_data_ready and set it to 0.

FreeRTOS

# Create a global variable sensor_data_ready and set it to 0
# Your code here

Hint

Use volatile int sensor_data_ready = 0; to declare the variable.

2

Create the FreeRTOS task

Create a FreeRTOS task function called SensorTask that runs an infinite loop and waits for a notification using ulTaskNotifyTake. Inside the loop, check if sensor_data_ready is 1, then clear it to 0.

FreeRTOS

volatile int sensor_data_ready = 0;

// Create SensorTask function
// Your code here

Hint

Use ulTaskNotifyTake(pdTRUE, portMAX_DELAY) to wait for notification.

3

Create the ISR to notify the task

Create an ISR function called SensorISR_Handler that sets sensor_data_ready to 1 and uses vTaskNotifyGiveFromISR to notify SensorTask. Assume SensorTaskHandle is the task handle for SensorTask.

FreeRTOS

volatile int sensor_data_ready = 0;

void SensorTask(void *pvParameters) {
    for (;;) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        if (sensor_data_ready == 1) {
            sensor_data_ready = 0;
            // Processing will be done in next step
        }
    }
}

TaskHandle_t SensorTaskHandle = NULL;

// Create ISR function SensorISR_Handler
// Your code here

Hint

Use vTaskNotifyGiveFromISR and portYIELD_FROM_ISR to notify the task safely from ISR.

4

Print output when processing sensor data

Inside SensorTask, after clearing sensor_data_ready, add a printf statement to print exactly "Processing sensor data...".

FreeRTOS

volatile int sensor_data_ready = 0;

void SensorTask(void *pvParameters) {
    for (;;) {
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);
        if (sensor_data_ready == 1) {
            sensor_data_ready = 0;
            // Print "Processing sensor data..." here
            // Your code here
        }
    }
}

TaskHandle_t SensorTaskHandle = NULL;

void SensorISR_Handler(void) {
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    sensor_data_ready = 1;
    vTaskNotifyGiveFromISR(SensorTaskHandle, &xHigherPriorityTaskWoken);
    portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}

Hint

Use printf("Processing sensor data...\n"); to print the message.

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