ISR best practices in Arduino - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does ISR stand for in Arduino programming?

ISR stands for Interrupt Service Routine. It is a special function that runs automatically when an interrupt occurs.

beginner

Why should ISRs be kept short and fast?

ISRs should be short and fast because they pause the main program. Long ISRs can cause delays and missed interrupts, making the program less responsive.

intermediate

Can you use functions like delay() inside an ISR? Why or why not?

No, you should not use delay() inside an ISR because delay() relies on interrupts to count time. Since interrupts are disabled during an ISR, delay() will not work and can cause the program to freeze.

intermediate

How should variables shared between an ISR and the main program be handled?

Variables shared between ISR and main code should be declared as volatile. This tells the compiler the variable can change anytime, preventing wrong optimizations.

beginner

What is the best way to communicate data from an ISR to the main program?

The best way is to set a flag or update a simple variable inside the ISR, then check and handle it in the main loop. Avoid complex processing inside the ISR.

What happens to the main program when an ISR runs?

A It pauses until the ISR finishes

B It continues running normally

C It restarts from the beginning

D It skips the ISR

When an ISR runs, the main program pauses until the ISR completes.

Which keyword should you use for variables shared between ISR and main code?

A static

B volatile

C const

D register

The volatile keyword tells the compiler the variable can change unexpectedly, which is important for ISR shared variables.

Which of these is safe to do inside an ISR?

A Set a flag variable

B Print to Serial

C Use delay() to wait

D Run a long loop

Setting a simple flag variable is safe and recommended inside an ISR.

Why should ISRs avoid long or complex code?

A Because ISRs run slower than main code

B Because ISRs only run once

C Because ISRs cannot access variables

D Because long ISRs block other interrupts and delay the main program

Long ISRs block other interrupts and delay the main program, reducing responsiveness.

What happens if you use delay() inside an ISR?

A The delay works normally

B The program crashes immediately

C The delay does not work and can freeze the program

D The ISR runs faster

delay() relies on interrupts, which are disabled during an ISR, so it will not work and can freeze the program.

Explain why ISRs should be short and what you should avoid doing inside them.

Think about how ISRs affect the main program's flow and timing.

Describe how to safely share data between an ISR and the main Arduino program.

Focus on variable declaration and communication method.

Practice

1. What is the main reason to keep Interrupt Service Routines (ISRs) short and simple in Arduino?

easy

A. To use more memory

B. To avoid delaying other important tasks and interrupts

C. To make the code look cleaner

D. To allow ISRs to run slower

Solution

1. Step 1: Understand ISR impact on program flow

   ISRs interrupt the main program to handle urgent events, so they must finish quickly to avoid blocking other tasks.

2. Step 2: Consider consequences of long ISRs

   If ISRs are long, they delay other interrupts and slow down the main program, causing performance issues.

3. Final Answer:

   To avoid delaying other important tasks and interrupts -> Option B

4. Quick Check:

   Keep ISRs short = avoid delays [OK]

Hint: Short ISR means faster response and less delay [OK]

Common Mistakes:

• Thinking ISR length only affects code readability
• Assuming ISRs can run as long as needed
• Ignoring impact on other interrupts

2. Which of the following is the correct way to declare a variable shared between an ISR and the main program?

easy

A. volatile int counter = 0;

B. int counter = 0;

C. static int counter = 0;

D. const int counter = 0;

Solution

1. Step 1: Identify variable usage in ISR and main code

   Variables shared between ISR and main code must be declared volatile to prevent compiler optimizations that cause wrong values.

2. Step 2: Check each declaration

   Only 'volatile int counter = 0;' tells the compiler the variable can change anytime, ensuring correct behavior.

3. Final Answer:

   volatile int counter = 0; -> Option A

4. Quick Check:

   Shared variable = volatile [OK]

Hint: Use volatile for variables changed in ISR [OK]

Common Mistakes:

• Forgetting volatile keyword
• Using const for variables that change
• Using static without volatile

3. What will be the output of this Arduino code snippet?

volatile int count = 0;
void setup() {
  Serial.begin(9600);
  attachInterrupt(digitalPinToInterrupt(2), increment, RISING);
}
void loop() {
  Serial.println(count);
  count = 0;
  delay(1000);
}
void increment() {
  count++;
}

Assuming pin 2 receives 3 rising signals per second, what will Serial print each second?

medium

A. 1

B. 0

C. 3

D. Random values

Solution

1. Step 1: Understand ISR increments

   Each rising signal on pin 2 triggers the ISR 'increment' which increases 'count' by 1.

2. Step 2: Calculate increments per second

   3 rising signals per second means 'count' increases by 3 every second.

3. Final Answer:

   3 -> Option C

4. Quick Check:

   3 signals/sec = count increments 3 times [OK]

Hint: ISR increments count per event; count matches event rate [OK]

Common Mistakes:

• Ignoring volatile keyword effect
• Assuming count resets automatically
• Thinking ISR runs slower than events

4. Identify the error in this ISR code snippet:

volatile int flag = 0;
void setup() {
  attachInterrupt(digitalPinToInterrupt(3), toggleFlag, FALLING);
}
void loop() {
  if(flag) {
    // do something
    flag = 0;
  }
}
void toggleFlag() {
  flag = !flag;
}

medium

A. Not declaring 'flag' as volatile

B. Missing Serial.begin() in setup

C. Incorrect interrupt mode FALLING

D. Using non-atomic operation on 'flag' inside ISR

Solution

1. Step 1: Analyze ISR operation on 'flag'

   The ISR toggles 'flag' using '!flag', which is a read-modify-write operation and not atomic.

2. Step 2: Understand atomicity importance

   Non-atomic operations on shared variables can cause race conditions and unpredictable behavior.

3. Final Answer:

   Using non-atomic operation on 'flag' inside ISR -> Option D

4. Quick Check:

   ISR must avoid non-atomic variable changes [OK]

Hint: Avoid read-modify-write on shared vars in ISR [OK]

Common Mistakes:

• Ignoring atomicity of operations
• Thinking volatile alone fixes all issues
• Confusing interrupt mode with logic error

5. You want to count button presses using an ISR on pin 2. Which approach best follows ISR best practices in Arduino?

hard

A. Increment a volatile counter in ISR; read and reset it safely in loop

B. Print a message directly inside the ISR using Serial.println()

C. Use delay() inside ISR to debounce the button

D. Declare the counter as static inside ISR without volatile

Solution

1. Step 1: Review ISR best practices for counting events

   ISRs should be short and only update volatile variables; printing or delays inside ISR are bad.

2. Step 2: Evaluate each option

   Increment a volatile counter in ISR; read and reset it safely in loop uses a volatile counter incremented in ISR and safely handled in loop, which is correct.

3. Final Answer:

   Increment a volatile counter in ISR; read and reset it safely in loop -> Option A

4. Quick Check:

   Keep ISR short; update volatile vars only [OK]

Hint: Update volatile counter in ISR; handle logic outside [OK]

Common Mistakes:

• Using Serial.print inside ISR causing delays
• Using delay() inside ISR causing blocking
• Not declaring shared variables volatile