ISR best practices (keep it short) in Embedded C - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why keep ISRs short?

Why is it important to keep Interrupt Service Routines (ISRs) short in embedded C programming?

A To enable ISRs to run in parallel with main code without synchronization

B To minimize interrupt latency and avoid blocking other interrupts

C To increase the stack size used by the ISR

D To allow ISRs to perform complex calculations without delay

💡 Hint

Think about how long the CPU is busy inside an ISR and how it affects other tasks.

Keeping ISRs short reduces the time the CPU spends handling interrupts, which lowers latency and prevents blocking other interrupts.

❓ Predict Output

intermediate

Output of ISR flag clearing code

What is the output of this embedded C code snippet after the ISR runs?

Embedded C

volatile int flag = 0;

void ISR_Handler() {
    flag = 1;
    // Clear interrupt flag here
}

int main() {
    flag = 0;
    ISR_Handler();
    if(flag == 1) {
        printf("Interrupt handled\n");
    } else {
        printf("No interrupt\n");
    }
    return 0;
}

A Runtime error due to flag not being volatile

B No interrupt

C Compilation error due to missing interrupt attribute

D Interrupt handled

💡 Hint

Consider what the ISR does to the flag variable and how main checks it.

The ISR sets the flag to 1, so main prints "Interrupt handled".

🔧 Debug

advanced

Identify the ISR bug causing missed interrupts

Which option shows the bug that can cause missed interrupts in this ISR code?

Embedded C

volatile int count = 0;

void ISR_Handler() {
    count++;
    // Missing interrupt flag clear
}

A ISR does not clear the interrupt flag, causing missed interrupts

B ISR uses a global variable, which is not allowed

C ISR increments count without disabling interrupts

D ISR uses a volatile variable, which is incorrect

💡 Hint

Think about what happens if the interrupt flag is not cleared inside the ISR.

If the interrupt flag is not cleared, the interrupt may not trigger again, causing missed interrupts.

📝 Syntax

advanced

Correct ISR declaration syntax

Which option shows the correct way to declare an ISR function in embedded C?

A void ISR_Handler() interrupt { /* code */ }

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

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

D void ISR_Handler(void) __interrupt { /* code */ }

💡 Hint

Check the placement of the __interrupt keyword and function signature.

The correct syntax places __interrupt before the function name with void parameter list.

🚀 Application

expert

Determine the number of ISR executions

Given this embedded C code, how many times will the ISR increment the counter if the interrupt triggers 5 times rapidly?

Embedded C

volatile int counter = 0;

void ISR_Handler() {
    counter++;
    // Interrupt flag cleared here
}

int main() {
    // Simulate 5 rapid interrupts
    for(int i=0; i<5; i++) {
        ISR_Handler();
    }
    printf("Counter: %d\n", counter);
    return 0;
}

A 5

B 1

C 0

D Undefined behavior

💡 Hint

Consider how many times the ISR is called and how it increments the counter.

The ISR is called 5 times in the loop, so the counter increments 5 times.

Practice

1. What is the main reason to keep Interrupt Service Routine (ISR) code short in embedded C?

easy

A. To use more memory for ISR variables

B. To enable ISR to call blocking functions safely

C. To allow ISR to run complex calculations

D. To avoid delaying other interrupts and keep system responsive

Solution

1. Step 1: Understand ISR impact on system

   ISRs temporarily stop main code and other interrupts, so long ISRs delay system response.

2. Step 2: Reason why short ISR is important

   Short ISR avoids blocking other interrupts and keeps system fast and responsive.

3. Final Answer:

   To avoid delaying other interrupts and keep system responsive -> Option D

4. Quick Check:

   Keep ISR short = avoid delays [OK]

Hint: Short ISR avoids blocking other interrupts [OK]

Common Mistakes:

• Thinking ISR can run long calculations
• Using blocking calls inside ISR
• Assuming ISR uses more memory for variables

2. Which of the following is the correct way to signal the main program from an ISR?

easy

A. Call a heavy processing function directly inside ISR

B. Print debug messages inside ISR

C. Set a flag variable that main code checks

D. Use a blocking delay inside ISR

Solution

1. Step 1: Identify safe communication from ISR

   Heavy processing or blocking calls inside ISR are unsafe; printing can cause delays.

2. Step 2: Use flag to communicate

   Setting a flag variable is fast and lets main code handle processing safely.

3. Final Answer:

   Set a flag variable that main code checks -> Option C

4. Quick Check:

   Use flags to signal main code [OK]

Hint: Use flags, not heavy calls, inside ISR [OK]

Common Mistakes:

• Calling complex functions inside ISR
• Using delays or blocking calls in ISR
• Printing inside ISR causing slowdowns

3. Given this ISR code snippet, what will be the value of flag after the interrupt triggers once?

volatile int flag = 0;
void ISR() {
  flag = 1;
}

medium

A. 1

B. 0

C. Undefined

D. ISR causes error

Solution

1. Step 1: Understand ISR effect on flag

   ISR sets flag to 1 when triggered.

2. Step 2: Check initial and final flag value

   Initially flag is 0, after ISR runs once, flag becomes 1.

3. Final Answer:

   1 -> Option A

4. Quick Check:

   ISR sets flag = 1 [OK]

Hint: ISR sets flag to 1 on trigger [OK]

Common Mistakes:

• Assuming flag stays 0
• Thinking ISR causes error
• Confusing volatile keyword effect

4. Identify the problem in this ISR code:

void ISR() {
  while(!data_ready) {
    // wait for data
  }
  process_data();
}

medium

A. Not setting a flag variable

B. Using a blocking loop inside ISR

C. ISR missing return statement

D. Using volatile variable incorrectly

Solution

1. Step 1: Analyze ISR code behavior

   ISR contains a while loop waiting for data_ready, which blocks ISR execution.

2. Step 2: Understand why blocking is bad in ISR

   Blocking inside ISR delays other interrupts and main code, causing system issues.

3. Final Answer:

   Using a blocking loop inside ISR -> Option B

4. Quick Check:

   Blocking loops inside ISR cause problems [OK]

Hint: Avoid loops that wait inside ISR [OK]

Common Mistakes:

• Ignoring blocking loops in ISR
• Thinking ISR needs return statement
• Confusing volatile usage

5. You want to handle a sensor interrupt by reading data and processing it. Which is the best approach following ISR best practices?

Options:
A) Read and process data fully inside ISR
B) Use delay inside ISR to wait for sensor
C) Set a flag in ISR and process data in main loop
D) Print sensor data inside ISR for debugging

hard

A. Set a flag in ISR and process data in main loop

B. Use delay inside ISR to wait for sensor

C. Read and process data fully inside ISR

D. Print sensor data inside ISR for debugging

Solution

1. Step 1: Evaluate ISR workload options

   Processing data fully or using delay inside ISR blocks system; printing slows ISR.

2. Step 2: Choose safe communication method

   Setting a flag in ISR and processing in main loop keeps ISR short and system responsive.

3. Final Answer:

   Set a flag in ISR and process data in main loop -> Option A

4. Quick Check:

   Flag in ISR, process later = best practice [OK]

Hint: Use flags in ISR, process outside [OK]

Common Mistakes:

• Doing heavy work inside ISR
• Using delays or prints in ISR
• Ignoring main loop processing