ISR best practices in Arduino - Deep Dive

Overview - ISR best practices in Arduino

What is it?

An ISR, or Interrupt Service Routine, is a special function in Arduino that runs automatically when a specific event happens, like a button press or a timer reaching zero. It pauses the main program to quickly handle the event and then returns control back. ISRs help Arduino respond immediately to important signals without waiting for the main program to check for them.

Why it matters

Without ISRs, Arduino would have to constantly check for events, which wastes time and can miss quick signals. ISRs let the board react instantly, making projects like alarms, sensors, or communication devices reliable and fast. Without good ISR practices, programs can crash or behave unpredictably, causing frustration and hardware issues.

Where it fits

Before learning ISRs, you should understand basic Arduino programming, including functions and variables. After mastering ISRs, you can explore advanced topics like timers, low-power modes, and real-time systems to build more responsive and efficient projects.

Mental Model

Core Idea

An ISR is like a fire alarm that interrupts normal activities to handle emergencies immediately and then lets life continue.

Think of it like...

Imagine you are reading a book (main program), and suddenly the fire alarm rings (interrupt). You stop reading instantly, deal with the emergency (ISR), and then go back to your book exactly where you left off.

Main Program Loop
┌─────────────────────────────┐
│                             │
│  Running normal code         │
│                             │
└─────────────┬───────────────┘
              │
              ▼
      Interrupt Occurs
┌─────────────────────────────┐
│                             │
│  ISR runs quickly            │
│                             │
└─────────────┬───────────────┘
              │
              ▼
      Return to Main Program

Build-Up - 7 Steps

1

Foundation

What is an ISR in Arduino

Concept: Introduce the basic idea of an Interrupt Service Routine and its role in Arduino.

An ISR is a special function that runs automatically when a hardware event happens, like pressing a button or a timer finishing. It interrupts the main program to handle the event quickly. You define an ISR using the attachInterrupt() function in Arduino.

Result

Arduino can respond immediately to events without waiting for the main loop.

Understanding that ISRs let Arduino react instantly to events is key to building responsive projects.

2

Foundation

How to attach an ISR in Arduino

Concept: Learn the syntax and basic usage of attachInterrupt() to link an ISR to a hardware event.

You use attachInterrupt(digitalPinToInterrupt(pin), ISR_function, mode) to tell Arduino which pin and event triggers the ISR. The mode can be RISING, FALLING, CHANGE, or LOW, defining when the ISR runs.

Result

The ISR runs automatically when the specified event happens on the chosen pin.

Knowing how to connect hardware events to code is the foundation for using ISRs effectively.

3

Intermediate

Keep ISRs short and fast

🤔Before reading on: Do you think it's okay to put long code or delays inside an ISR? Commit to your answer.

Concept: ISRs should run quickly without delays or heavy processing to avoid blocking other important tasks.

Inside an ISR, avoid using delay(), Serial.print(), or long loops. Instead, set flags or update simple variables. The main program can then handle complex tasks based on these flags.

Result

The program remains responsive and avoids crashes or missed interrupts.

Understanding that ISRs block other code while running explains why they must be short and efficient.

4

Intermediate

Use volatile variables for shared data

🤔Before reading on: Should variables changed inside an ISR be declared volatile? Commit to your answer.

Concept: Variables shared between ISRs and the main program must be declared volatile to prevent compiler optimizations that cause bugs.

Declare variables modified in ISRs as volatile. This tells the compiler the variable can change anytime, so it always reads the latest value from memory.

Result

Data shared between ISR and main code stays accurate and consistent.

Knowing how volatile works prevents subtle bugs where the main program uses outdated variable values.

5

Intermediate

Avoid using non-atomic operations in ISRs

Concept: Operations like reading or writing multi-byte variables can be interrupted and cause inconsistent data.

For example, reading a 16-bit variable can be split into two 8-bit reads. If an ISR changes the variable between these reads, the main program gets wrong data. Use noInterrupts() and interrupts() to protect such operations.

Result

Data integrity is maintained even when ISRs and main code access the same variables.

Understanding atomicity helps prevent hard-to-find bugs in concurrent code.

6

Advanced

Nested interrupts and priorities

🤔Before reading on: Can Arduino ISRs interrupt other ISRs? Commit to your answer.

Concept: Arduino disables interrupts during an ISR, so nested interrupts are usually not possible unless explicitly enabled.

By default, when an ISR runs, other interrupts are disabled to avoid conflicts. Advanced users can enable nested interrupts, but this requires careful design to avoid crashes.

Result

Knowing this helps design safe and predictable interrupt-driven programs.

Recognizing interrupt priority and nesting limitations prevents unexpected program behavior.

7

Expert

ISR pitfalls: Serial and memory functions

🤔Before reading on: Is it safe to use Serial.print() inside an ISR? Commit to your answer.

Concept: Functions like Serial.print() and dynamic memory allocation are not safe inside ISRs because they rely on interrupts and can cause deadlocks or crashes.

Serial.print() waits for interrupts to send data, but interrupts are disabled inside ISRs, causing the program to freeze. Similarly, malloc() or free() can corrupt memory if called inside ISRs.

Result

Avoiding these functions inside ISRs keeps the program stable and responsive.

Knowing which functions are unsafe inside ISRs is critical for robust embedded programming.

Under the Hood

When a hardware event triggers an interrupt, the Arduino CPU pauses the current instruction, saves its place, and jumps to the ISR code. During the ISR, interrupts are disabled to prevent conflicts. After the ISR finishes, the CPU restores the saved state and resumes the main program exactly where it left off.

Why designed this way?

Disabling interrupts during ISR execution prevents multiple ISRs from interfering with each other and causing data corruption. This design balances responsiveness with program stability. Alternatives like nested interrupts add complexity and risk, so the default is safer for most applications.

┌───────────────┐
│ Main Program  │
│ Running Code  │
└──────┬────────┘
       │ Interrupt Occurs
       ▼
┌───────────────┐
│ Save Context  │
│ Disable IRQs  │
│ Run ISR       │
│ Restore Context│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Resume Main   │
│ Program       │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Can you safely use delay() inside an ISR? Commit to yes or no.

Common Belief: It's fine to use delay() inside an ISR to wait for some time.

Reality: delay() relies on interrupts to count time, but interrupts are disabled inside ISRs, so delay() will freeze the program.

Why it matters: Using delay() inside ISRs causes the program to hang, making the device unresponsive.

Quick: Do variables shared between ISR and main code need special declaration? Commit to yes or no.

Common Belief: Variables used in ISRs and main code don't need special handling.

Reality: They must be declared volatile to ensure the compiler always reads the latest value.

Why it matters: Without volatile, the main program may use outdated values, causing incorrect behavior.

Quick: Can ISRs call Serial.print() safely? Commit to yes or no.

Common Belief: Serial.print() works fine inside ISRs for debugging.

Reality: Serial.print() depends on interrupts, which are disabled in ISRs, causing the program to freeze or crash.

Why it matters: Using Serial.print() inside ISRs leads to hard-to-debug freezes and unstable programs.

Quick: Can Arduino ISRs interrupt other ISRs? Commit to yes or no.

Common Belief: ISRs can interrupt each other freely, allowing nested interrupts.

Reality: By default, interrupts are disabled during ISR execution, so nested interrupts do not occur unless explicitly enabled.

Why it matters: Assuming nested interrupts can cause design errors and unexpected program behavior.

Expert Zone

1

Some Arduino boards and microcontrollers support hardware priorities for interrupts, allowing critical ISRs to preempt less important ones, but this requires advanced configuration.

2

Using atomic blocks or disabling interrupts briefly in the main code protects multi-byte shared variables without needing complex synchronization primitives.

3

Certain libraries provide safe wrappers for ISR communication, like ring buffers for serial data, which avoid common pitfalls of shared data.

When NOT to use

Avoid using ISRs for heavy processing or long tasks; instead, use them only to set flags or capture data quickly. For complex timing or multitasking, consider using RTOS (Real-Time Operating Systems) or state machines.

Production Patterns

In real-world Arduino projects, ISRs often set flags or increment counters, while the main loop handles processing. Timers and external interrupts are used for precise timing and event detection, with careful attention to volatile variables and minimal ISR code.

Connections

Real-Time Operating Systems (RTOS)

Builds-on

Understanding ISRs helps grasp how RTOS manage tasks and interrupts to achieve precise timing and multitasking.

Concurrency in Computer Science

Same pattern

ISRs are a form of concurrency where multiple flows of execution share resources, teaching principles of synchronization and atomicity.

Emergency Response Systems

Analogy-based

Just like ISRs handle urgent events immediately, emergency systems prioritize critical incidents to maintain safety and order.

Common Pitfalls

#1 Using delay() inside an ISR causes the program to freeze.

Wrong approach:

void ISR() {
delay(1000); // Wait 1 second inside ISR
}

Correct approach:

volatile bool flag = false;
void ISR() {
flag = true; // Set flag quickly
}
// In main loop:
if (flag) {
delay(1000); // Handle delay outside ISR
flag = false;
}

Root cause:

delay() depends on interrupts, which are disabled inside ISRs, causing deadlock.

#2 Not declaring shared variables as volatile leads to wrong values.

Wrong approach:

int count = 0;
void ISR() {
count++;
}
void loop() {
if (count > 0) {
// Do something
}
}

Correct approach:

volatile int count = 0;
void ISR() {
count++;
}
void loop() {
if (count > 0) {
// Do something
}
}

Root cause:

Compiler optimizes non-volatile variables assuming they don't change unexpectedly.

#3 Calling Serial.print() inside ISR causes program freeze.

Wrong approach:

void ISR() {
Serial.print("Interrupt!");
}

Correct approach:

volatile bool flag = false;
void ISR() {
flag = true;
}
void loop() {
if (flag) {
Serial.print("Interrupt!");
flag = false;
}
}

Root cause:

Serial.print() requires interrupts enabled, which are disabled inside ISRs.

Key Takeaways

ISRs let Arduino respond immediately to hardware events by temporarily pausing the main program.

Keep ISR code short and avoid functions like delay() or Serial.print() to prevent freezing or crashes.

Declare variables shared between ISRs and main code as volatile to ensure data consistency.

Understand that interrupts are disabled during ISR execution, so nested interrupts do not happen by default.

Use ISRs to set flags or update simple data, and handle complex processing in the main loop for stable programs.