Button with interrupt (GPIO.add_event_detect) in Raspberry Pi - Step-by-Step Execution

Concept Flow - Button with interrupt (GPIO.add_event_detect)

Setup GPIO pin as input

↓

Attach event detect on pin

↓

Wait for button press

↓

Interrupt triggers callback

↓

Callback runs user code

↓

Return to waiting for next press

The program sets a pin as input, attaches an event detect to watch for button presses, and runs a callback function automatically when the button is pressed.

Execution Sample

Raspberry Pi

import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
GPIO.setup(18, GPIO.IN, pull_up_down=GPIO.PUD_UP)

def button_pressed(channel):
    print("Button was pressed!")

GPIO.add_event_detect(18, GPIO.FALLING, callback=button_pressed, bouncetime=200)

while True:
    pass

This code waits for a button press on pin 18 and prints a message when pressed, using an interrupt callback.

Execution Table

Step	Action	Pin State	Event Detected?	Callback Called	Output
1	Setup pin 18 as input with pull-up	HIGH (not pressed)	No	No
2	Attach event detect on FALLING edge	HIGH	No	No
3	Wait for button press	HIGH	No	No
4	Button pressed, pin goes LOW	LOW (pressed)	Yes	Yes	Button was pressed!
5	Callback runs and returns	LOW	No	No
6	Button released, pin goes HIGH	HIGH (not pressed)	No	No
7	Wait for next press	HIGH	No	No

💡 Program runs indefinitely, waiting for button presses and calling callback on each press.

Variable Tracker

Variable	Start	After Setup	After Press	After Callback	Final
Pin 18 State	Undefined	HIGH (not pressed)	LOW (pressed)	LOW (pressed)	HIGH (not pressed)
Event Detected	False	False	True	False	False
Callback Called	False	False	True	True	False

Key Moments - 3 Insights

Why does the callback run only when the button is pressed and not all the time?

Because the event detect is set to trigger only on the FALLING edge (pin going from HIGH to LOW), as shown in execution_table rows 4 and 5.

What is the purpose of the 'bouncetime' parameter in add_event_detect?

It prevents multiple triggers caused by the button physically bouncing, ensuring the callback runs only once per press, as implied in the stable callback calls in the execution_table.

Why do we use pull_up_down=GPIO.PUD_UP when setting up the pin?

It keeps the pin normally HIGH when the button is not pressed, so pressing the button pulls it LOW, which the event detect watches for, as seen in the Pin State changes in the execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the callback function first run?

A Step 6

B Step 3

C Step 4

D Step 7

💡 Hint

Check the 'Callback Called' column in execution_table rows.

According to variable_tracker, what is the pin state after the button is pressed?

A HIGH (not pressed)

B LOW (pressed)

C Undefined

D Floating

💡 Hint

Look at 'Pin 18 State' values after press in variable_tracker.

If we remove the 'bouncetime' parameter, what might happen?

A Callback might run multiple times per press

B Callback will never run

C Pin state will stay HIGH

D Program will crash

💡 Hint

Think about what 'bouncetime' prevents as explained in key_moments.

Concept Snapshot

Setup GPIO pin as input with pull-up resistor
Attach event detect on FALLING edge with callback
When button pressed, pin goes LOW triggering callback
Callback runs user code (e.g., print message)
Use bouncetime to avoid multiple triggers
Program waits indefinitely for button presses

Full Transcript

This example shows how to use GPIO.add_event_detect on a Raspberry Pi to detect button presses. First, the GPIO pin 18 is set as input with a pull-up resistor, so it reads HIGH normally. Then, an event detect is attached to watch for the FALLING edge, which happens when the button is pressed and the pin goes LOW. When this event occurs, the callback function button_pressed runs and prints a message. The program waits in an infinite loop doing nothing else, relying on interrupts to respond to button presses. The bouncetime parameter helps prevent multiple triggers caused by button bounce. The execution table traces the pin state and callback calls step-by-step, and the variable tracker shows how pin state and event flags change over time.