Writing an ISR (Interrupt Service Routine) in Embedded C - Time & Space Complexity

Time Complexity: Writing an ISR (Interrupt Service Routine)

O(1)

Understanding Time Complexity

When writing an ISR, it's important to know how long it takes to run as input changes.

We want to see how the ISR's work grows when it handles more data or events.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

volatile int data_ready = 0;
int buffer[100];
int index = 0;

void ISR_Handler() {
    if (data_ready) {
        buffer[index++] = read_sensor();
        if (index >= 100) {
            index = 0;
        }
        data_ready = 0;
    }
}

This ISR reads sensor data when ready and stores it in a buffer, resetting when full.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Reading sensor data and storing it once per interrupt.
• How many times: Once each time the interrupt triggers, no loops inside ISR.

How Execution Grows With Input

The ISR does a fixed amount of work each time it runs, no matter how many times it has run before.

Input Size (n)	Approx. Operations
10 interrupts	10 sensor reads and stores
100 interrupts	100 sensor reads and stores
1000 interrupts	1000 sensor reads and stores

Pattern observation: Each interrupt causes a fixed small task, so work grows directly with number of interrupts.

Final Time Complexity

Time Complexity: O(1)

This means the ISR runs in constant time each time it is called, regardless of input size.

Common Mistake

[X] Wrong: "The ISR time grows with how many times it has run before because the buffer fills up."

[OK] Correct: The ISR only does a fixed set of steps each call; it does not loop over the whole buffer.

Interview Connect

Understanding ISR time helps you write fast, reliable embedded code that keeps systems responsive.

Self-Check

"What if the ISR had a loop to process all buffer elements each time? How would the time complexity change?"

Practice

1. What is the main purpose of an ISR (Interrupt Service Routine) in embedded C?

easy

A. To allocate memory dynamically

B. To handle hardware events immediately when they occur

C. To run the main program loop continuously

D. To compile the program code

Solution

1. Step 1: Understand ISR role

   An ISR is a special function that runs automatically when a hardware event happens, like a button press or timer overflow.

2. Step 2: Compare options

   Only To handle hardware events immediately when they occur describes this immediate handling of hardware events. Other options describe unrelated tasks.

3. Final Answer:

   To handle hardware events immediately when they occur -> Option B

4. Quick Check:

   ISR = handle hardware events [OK]

Hint: ISRs respond instantly to hardware signals [OK]

Common Mistakes:

• Thinking ISR runs like normal functions
• Confusing ISR with main program loop
• Assuming ISR manages memory

2. Which of the following is the correct way to declare an ISR function in embedded C?

easy

A. void ISR_Handler() __interrupt { /* code */ }

B. void ISR_Handler() interrupt { /* code */ }

C. void ISR_Handler() __interrupt(0) { /* code */ }

D. void ISR_Handler() __isr { /* code */ }

Solution

1. Step 1: Recall ISR syntax in embedded C

   ISRs are declared with the __interrupt keyword followed by the interrupt vector number in parentheses.

2. Step 2: Check options

   void ISR_Handler() __interrupt(0) { /* code */ } uses __interrupt(0), which is the correct syntax. The others either miss the vector number, use the wrong keyword ('interrupt'), or a non-standard keyword ('__isr').

3. Final Answer:

   void ISR_Handler() __interrupt(0) { /* code */ } -> Option C

4. Quick Check:

   ISR syntax = __interrupt(vector) [OK]

Hint: Use __interrupt(vector_number) to declare ISR [OK]

Common Mistakes:

• Omitting interrupt vector number
• Using 'interrupt' instead of '__interrupt'
• Using non-standard keywords

3. Given the following ISR code snippet, what will be the value of flag after the interrupt occurs?

volatile int flag = 0;
void ISR_Timer() __interrupt(1) {
    flag = 1;
    // Interrupt flag cleared here
}

int main() {
    flag = 0;
    // Interrupt occurs here
    // ISR_Timer runs
    return flag;
}

medium

A. 1

B. 0

C. Undefined behavior

D. Compilation error

Solution

1. Step 1: Understand ISR effect on flag

   The ISR sets the variable 'flag' to 1 when the interrupt occurs.

2. Step 2: Check main function return

   Main sets flag to 0, then interrupt triggers ISR which sets flag to 1, so return value is 1.

3. Final Answer:

   1 -> Option A

4. Quick Check:

   ISR sets flag = 1, so return = 1 [OK]

Hint: ISR changes flag to 1 before main returns [OK]

Common Mistakes:

• Ignoring ISR effect on flag
• Assuming flag stays 0
• Confusing volatile usage

4. Identify the error in this ISR code snippet:

void ISR_UART() __interrupt(4) {
    if (UART_Interrupt_Flag) {
        // Handle UART interrupt
        UART_Interrupt_Flag = 0;
    }
}

medium

A. ISR should not clear interrupt flags inside it

B. ISR function must return an int value

C. ISR must be declared with 'interrupt' keyword, not '__interrupt'

D. Missing volatile keyword for UART_Interrupt_Flag variable

Solution

1. Step 1: Check variable usage in ISR

   Interrupt flags accessed in ISR should be declared volatile to prevent compiler optimization issues.

2. Step 2: Analyze other options

   Clearing flags inside ISR is correct practice; __interrupt is correct keyword; ISR functions return void, not int.

3. Final Answer:

   Missing volatile keyword for UART_Interrupt_Flag variable -> Option D

4. Quick Check:

   Interrupt flags must be volatile [OK]

Hint: Declare interrupt flags volatile to avoid optimization bugs [OK]

Common Mistakes:

• Not declaring flags volatile
• Wrong ISR declaration keyword
• Expecting ISR to return a value

5. You want to write an ISR for a timer interrupt that increments a counter and clears the interrupt flag. Which of the following is the best practice to ensure correct ISR behavior?

hard

A. Increment counter, then clear interrupt flag inside ISR

B. Clear interrupt flag, then increment counter inside ISR

C. Increment counter outside ISR and clear flag inside ISR

D. Do not clear interrupt flag; let main program clear it

Solution

1. Step 1: Understand ISR order for flag and counter

   Best practice is to handle the event (increment counter) first, then clear the interrupt flag to acknowledge the interrupt.

2. Step 2: Evaluate options

   Increment counter, then clear interrupt flag inside ISR follows this order. Clear interrupt flag, then increment counter inside ISR clears flag before handling event, which may cause missed interrupts. Increment counter outside ISR and clear flag inside ISR splits logic incorrectly. Do not clear interrupt flag; let main program clear it risks repeated interrupts.

3. Final Answer:

   Increment counter, then clear interrupt flag inside ISR -> Option A

4. Quick Check:

   Handle event first, then clear flag [OK]

Hint: Process event before clearing interrupt flag [OK]

Common Mistakes:

• Clearing flag before handling event
• Leaving flag uncleared causing repeated interrupts
• Handling event outside ISR