Handling Asynchronous Events with Hardware Interrupts on Arduino AVR

The Problem: Polling Latency and Missed Events

In standard Arduino programming, checking for a button press or a sensor trigger usually happens inside the loop() function. This is called polling. If your code contains delay() calls or complex calculations, the processor is "blind" to input changes until it reaches the specific line of code that checks the pin state. This leads to missed triggers or sluggish system responsiveness.

Hardware interrupts solve this by allowing the microcontroller (MCU) to pause its current task immediately when a specific electrical event occurs on a pin, execute a dedicated function, and then return to where it left off. This ensures that critical events are captured regardless of what the main program is doing.

Hardware Requirements and Constraints

Not every pin on an Arduino board supports hardware interrupts. For AVR-based boards like the Arduino Uno and Nano, only digital pins 2 and 3 are equipped for this functionality. To implement an interrupt, you will need:

• An Arduino Uno, Nano, or Pro Mini (ATmega328P).
• A momentary switch or digital sensor connected to pin 2 or 3.
• A pull-up or pull-down resistor to prevent a "floating" pin, which can cause random, phantom triggers.

Implementing the Interrupt Service Routine (ISR)

An Interrupt Service Routine (ISR) is the function that runs when the interrupt is triggered. Because the ISR pauses the main program, it must be designed for speed and efficiency.

Configuration Example

// Pin 2 is the interrupt pin
const byte interruptPin = 2;
// Variable shared between ISR and main loop must be volatile
volatile bool eventTriggered = false;

void setup() {
  Serial.begin(9600);
  pinMode(13, OUTPUT); // Built-in LED
  
  // Use internal pull-up to keep pin HIGH until pressed to GND
  pinMode(interruptPin, INPUT_PULLUP);

  // attachInterrupt(digitalPinToInterrupt(pin), ISR_function, mode)
  attachInterrupt(digitalPinToInterrupt(interruptPin), handleEvent, FALLING);
}

void loop() {
  // Main loop can have long delays, but the ISR will still fire
  delay(1000);
  
  if (eventTriggered) {
    Serial.println("Event captured!");
    digitalWrite(13, HIGH);
    delay(100);
    digitalWrite(13, LOW);
    eventTriggered = false; // Reset the flag
  }
}

// The ISR: Keep this as short as possible
void handleEvent() {
  eventTriggered = true;
}

Critical Engineering Decisions

The Volatile Keyword

When you declare volatile bool eventTriggered, you tell the compiler that this variable can change unexpectedly outside the normal program flow. Without volatile, the compiler might optimize the loop() by assuming the variable never changes if it doesn't see a change happening within the loop itself, causing your program to ignore the interrupt.

Trigger Modes

The attachInterrupt() function accepts four modes based on the signal transition:

Mode	Trigger Condition	Typical Use Case
LOW	Pin is held at 0V	Continuous signal detection
CHANGE	Pin goes HIGH to LOW or LOW to HIGH	Toggling a state
RISING	Pin goes LOW to HIGH	Active-high sensor triggers
FALLING	Pin goes HIGH to LOW	Active-low buttons (with pull-ups)

Operational Limitations and Risks

• No Delays: The delay() function relies on timer interrupts. Since interrupts are disabled inside an ISR, delay() will not work and may hang the MCU.
• Serial Communication: Avoid Serial.print() inside an ISR. Serial communication uses interrupts to send data; calling it inside an ISR can lead to a deadlock or system crash.
• Interrupt Storms: If a sensor triggers thousands of times per second (or if a button bounces), the MCU will spend all its time in the ISR, starving the loop() of CPU cycles. This manifests as a frozen system.

Verification and Testing

To verify the implementation, upload the provided example and open the Serial Monitor. Press the button connected to pin 2. Even though there is a delay(1000) in the loop, the eventTriggered flag should be set immediately. You can confirm this by observing the LED on pin 13; it should blink shortly after the press, but only once the loop() reaches the if statement.

Rollback and Cleanup

If you need to disable the interrupt during a specific phase of your program (e.g., during a calibration sequence), use the following command:

detachInterrupt(digitalPinToInterrupt(interruptPin));

This restores the pin to a standard digital input and prevents the ISR from firing until attachInterrupt() is called again.