attachInterrupt() function in Arduino - Time & Space Complexity
When using the attachInterrupt() function, it's important to understand how often the interrupt code runs as input changes.
We want to know how the time spent in the interrupt grows as events happen.
Analyze the time complexity of the following code snippet.
volatile int count = 0;
void setup() {
attachInterrupt(digitalPinToInterrupt(2), countPulse, RISING);
}
void countPulse() {
count++;
}
void loop() {
// main code runs here
}
This code counts how many times a signal rises on pin 2 using an interrupt.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The interrupt service routine
countPulse()runs each time the signal rises. - How many times: It runs once per rising signal event, which depends on external input frequency.
The time spent in countPulse() grows directly with the number of rising signals detected.
| Input Size (number of rising signals) | Approx. Operations (interrupt calls) |
|---|---|
| 10 | 10 calls to countPulse() |
| 100 | 100 calls to countPulse() |
| 1000 | 1000 calls to countPulse() |
Pattern observation: The number of interrupt calls grows linearly with the number of signal events.
Time Complexity: O(n)
This means the total time spent in the interrupt grows directly with the number of signal events.
[X] Wrong: "The interrupt runs constantly and uses the same time no matter how many signals come."
[OK] Correct: The interrupt only runs when a signal event happens, so more events mean more interrupt calls and more time spent.
Understanding how interrupts affect program timing helps you write responsive and efficient code in real projects.
What if the interrupt routine did more work inside? How would that affect the time complexity?
Practice
attachInterrupt() function in Arduino?Solution
Step 1: Understand the role of attachInterrupt()
The functionattachInterrupt()is used to make Arduino respond immediately when a pin changes, without waiting for the main loop.Step 2: Identify the correct purpose
It triggers a specific function automatically on pin state changes, unlike other options which are unrelated to interrupts.Final Answer:
To run a function automatically when a specific pin changes state -> Option CQuick Check:
attachInterrupt() triggers functions on pin changes [OK]
- Confusing attachInterrupt() with serial communication setup
- Thinking it starts the main loop
- Mixing it with variable declarations
handleInterrupt?Solution
Step 1: Recall correct attachInterrupt() syntax
The correct syntax usesdigitalPinToInterrupt(pin)to convert the pin number to an interrupt number.Step 2: Match parameters order
The order is: interrupt number, function name, mode (like RISING). Only attachInterrupt(digitalPinToInterrupt(2), handleInterrupt, RISING); follows this correctly.Final Answer:
attachInterrupt(digitalPinToInterrupt(2), handleInterrupt, RISING); -> Option BQuick Check:
Use digitalPinToInterrupt(pin) for correct interrupt number [OK]
- Passing pin number directly without digitalPinToInterrupt()
- Mixing parameter order
- Using pin number instead of interrupt number
volatile int count = 0;
void setup() {
Serial.begin(9600);
pinMode(2, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(2), incrementCount, FALLING);
}
void loop() {
Serial.println(count);
delay(500);
}
void incrementCount() {
count++;
}Solution
Step 1: Analyze interrupt setup and button wiring
The button is connected to pin 2 with INPUT_PULLUP, so pressing it pulls pin 2 LOW, triggering FALLING edge interrupt.Step 2: Understand interrupt effect on count
Each button press triggersincrementCount(), increasingcountby 1, which is printed repeatedly in loop.Final Answer:
The count will increase by 1 each time the button is pressed -> Option DQuick Check:
Interrupt increments count on button press [OK]
- Ignoring INPUT_PULLUP logic and edge type
- Assuming count won't change without delay
- Thinking volatile causes crashes
attachInterrupt():volatile int flag = 0;
void setup() {
pinMode(3, INPUT);
attachInterrupt(3, interruptHandler, CHANGE);
}
void loop() {
if (flag == 1) {
Serial.println("Interrupt triggered");
flag = 0;
}
}
void interruptHandler() {
flag = 1;
}Solution
Step 1: Check attachInterrupt() parameter usage
The first parameter must be the interrupt number, obtained by digitalPinToInterrupt(pin), not the pin number directly.Step 2: Verify other parts
CHANGE is a valid mode, flag should be volatile, and interrupt handlers return void, so no other errors.Final Answer:
Pin number 3 is used directly instead of digitalPinToInterrupt(3) -> Option AQuick Check:
Use digitalPinToInterrupt(pin) for correct interrupt number [OK]
- Passing pin number directly to attachInterrupt()
- Misunderstanding valid interrupt modes
- Incorrect return type for interrupt handler
attachInterrupt() is best?Solution
Step 1: Understand the need for debouncing or filtering
To avoid false triggers, you must check if the LOW state lasts at least 50ms, which requires timing logic outside the interrupt.Step 2: Evaluate options for timing and counting
Using CHANGE interrupt and recording time in ISR, then checking duration in loop() allows safe timing without delay() inside ISR, which is not allowed.Step 3: Reject unsafe or incorrect options
Usingdelay()inside the ISR is bad practice; incrementing the count immediately on an edge without checking duration ignores the 50ms requirement.Final Answer:
Use attachInterrupt() on CHANGE, record the time in ISR, and check duration in loop() -> Option AQuick Check:
Record time in ISR, check duration in loop for debounce [OK]
- Using delay() inside interrupt routine
- Ignoring debounce timing
- Incrementing count immediately on edge
Ready to prove it?
Pass the test and this pattern moves unknown
