GPIO, pull-ups, debouncing and interrupts

General-purpose input/output (GPIO) pins are a microcontroller's simplest connection to the world. As outputs they switch LEDs, enable motor drivers and select devices; as inputs they read buttons, limit switches, bumpers, emergency-stop status and the pulses from wheel encoders. Simple as they are, GPIOs cause a surprising share of robot faults: inputs that float and read random values, switches that register ten presses instead of one, encoders that lose counts at speed, and outputs asked to supply more current than they can. This lesson explains how GPIO pins work electrically, how pull-up and pull-down resistors define idle states, how to debounce mechanical switches, and how interrupts let a microcontroller respond to events within microseconds without wasting time watching for them.

Inside a GPIO pin

Each GPIO pin connects to a small circuit that can be configured in software. As a push-pull output, two transistors drive the pin: one connects it to the supply to output a high, the other to ground for a low. As an open-drain output, only the low-side transistor is present; the pin can pull low or let go, and an external or internal resistor pulls it high when released. Open-drain outputs from several devices can share one wire safely, because no device ever drives the wire high against another driving it low, which is why I2C and many interrupt and reset lines use them. As an input, the drivers are switched off and the pin's voltage goes to a buffer, often with an optional Schmitt trigger. Most pins also have optional internal pull-up and pull-down resistors, typically 20 to 50 kΩ, and many can be connected to alternate functions such as a timer output or a UART.

Output pins can source or sink only limited current, often 4 to 20 mA per pin, with a lower limit for the whole chip or for each group of pins. As the current rises, the output voltage moves away from the rail because of the transistors' resistance. Driving an LED at a few milliamperes is fine; driving a relay, a motor or a long LED strip directly is not. Use the switching circuits from lesson 3, and treat datasheet absolute maximum ratings as limits never to approach, not targets.

Floating inputs and pull resistors

An input pin connected to nothing is floating. Its input impedance is extremely high, so it picks up stray charge and nearby signals, reading 0 or 1 at random and sometimes oscillating, which wastes power and produces phantom button presses. Every input must be driven to a defined level at all times. A pull-up resistor connects the input to the supply, so it reads 1 until a switch connects it to ground; a pull-down does the opposite. The pull-up arrangement with the switch to ground is the most common, which makes the input active-low: pressed reads 0.

Choosing the resistor is a trade-off. When the switch is closed, the resistor draws \( V/R \) continuously, so lower values waste more power: 3.3 V across 1 kΩ is 3.3 mA. Higher values save power but make the input more sensitive to noise and slower to return high, because the pin and wire capacitance must charge through the resistor. Values of 4.7 to 10 kΩ are typical for switches on a robot; the internal 20 to 50 kΩ pull-ups are fine for buttons on a board but marginal for long wires to a bumper on the far side of a chassis.

Switch bounce

When a mechanical switch closes, its contacts do not meet cleanly. They bounce apart and together several times over a few hundred microseconds to several milliseconds, so the input sees a burst of transitions. A program counting presses or reacting to each edge sees many events instead of one. Bumpers, limit switches, buttons and reed switches all bounce. Debouncing fixes this, either in hardware with a resistor-capacitor filter followed by a Schmitt-trigger input, or in software by requiring the input to be stable for a set time before accepting a change.

A common software approach samples the input at a fixed rate, say every millisecond from a timer, and changes the reported state only after the raw reading has differed from it for a set number of consecutive samples. The listing below simulates this on a recorded bouncy press and release, sampled every millisecond, and compares a naive edge counter with a debouncer that needs five stable samples.

# 1 = released (pull-up), 0 = pressed. One sample per millisecond.
raw = ([1]*5 + [0,1,0,0,1,0,1,0,0,0] + [0]*20 +     # bouncy press
       [1,0,1,1,0,1,1,1] + [1]*15)                  # bouncy release

naive_presses = sum(1 for a, b in zip(raw, raw[1:]) if a == 1 and b == 0)

def debounce(samples, needed=5):
    state, count, events = samples[0], 0, []
    for t, s in enumerate(samples):
        if s != state:
            count += 1
            if count >= needed:
                state, count = s, 0
                events.append((t, "pressed" if s == 0 else "released"))
        else:
            count = 0
    return events

print("naive falling edges:", naive_presses)
for t, what in debounce(raw):
    print(f"debounced: {what} at t = {t} ms")

naive falling edges: 6
debounced: pressed at t = 16 ms
debounced: released at t = 44 ms

The naive counter sees six presses; the debouncer reports one press and one release, each a few milliseconds after the switch has settled. Five milliseconds of delay is unnoticeable for a button and acceptable for most bumpers, but too slow for something like a homing switch on a fast axis, where a hardware filter or a better sensor such as an optical or Hall-effect switch, which does not bounce, is the better choice. Safety inputs such as emergency-stop chains should be handled by dedicated hardware rather than debounced in software.

Polling and interrupts

A program can find out about an input change in two ways. Polling reads the pin regularly in the main loop or a timer task. It is simple, predictable and fine for slow signals such as buttons, but it can miss short pulses and wastes time checking pins that rarely change. An interrupt makes the hardware watch the pin and, on a configured edge, pause the main program, run a short function called an interrupt service routine (ISR), and return. Interrupt latency, the delay from the edge to the first instruction of the ISR, is typically well under a microsecond on a Cortex-M microcontroller, so interrupts are the tool for fast or rare events: encoder pulses, a data-ready signal from a sensor, a fault output from a motor driver.

ISRs must be short. While one runs, other interrupts of equal or lower priority wait, and the main program is frozen. The rule is to do the minimum in the ISR, such as recording a timestamp, incrementing a counter or setting a flag, and leave the processing to the main loop or a task. Variables shared between an ISR and the main program must be volatile, and multi-byte values must be read with interrupts briefly disabled, or by other atomic means, so the main program never sees half of an old value and half of a new one. Interrupt priorities, configured in the interrupt controller (the NVIC on Arm Cortex-M), let urgent events such as a motor-driver fault pre-empt less urgent ones.

#include <stdint.h>
#include <stdbool.h>

static volatile int32_t  g_count = 0;     /* encoder position */
static volatile bool     g_fault = false;

/* Called on every edge of encoder channel A (both edges enabled). */
void EXTI0_IRQHandler(void) {
    exti_clear_flag(0);
    bool a = gpio_read(ENC_A), b = gpio_read(ENC_B);
    g_count += (a == b) ? -1 : +1;          /* direction from phase */
}

/* Motor driver fault output, active low: highest priority. */
void EXTI1_IRQHandler(void) {
    exti_clear_flag(1);
    motor_disable_all();                     /* act immediately */
    g_fault = true;                          /* report to main loop */
}

int32_t encoder_read(void) {
    __disable_irq();                         /* read atomically */
    int32_t c = g_count;
    __enable_irq();
    return c;
}

Quadrature encoders

Wheel and joint encoders usually produce two square waves, channels A and B, a quarter cycle apart, in quadrature. The order of the edges tells the direction: if A leads B the shaft turns one way, if B leads A the other. Counting every edge on both channels, called 4× decoding, gives four counts per cycle. An encoder rated at 500 cycles per revolution therefore gives 2,000 counts per revolution with 4× decoding. Many robots mount the encoder on the motor shaft before the gearbox, multiplying the resolution at the wheel by the gear ratio.

The edge rate determines whether the microcontroller can keep up. At speed, an interrupt per edge can overwhelm the processor, so serious motor controllers use timer peripherals with built-in quadrature decoder modes that count edges in hardware, with no software involvement, as lesson 7 notes.

def edge_rate(rpm, cpr, decoding=4):
    return rpm / 60 * cpr * decoding

for rpm in (300, 3000, 6000, 12000):
    rate = edge_rate(rpm, 1024)
    print(f"{rpm:6d} rpm -> {rate/1000:7.1f} k edges/s, "
          f"CPU at 0.8 us each: {rate*0.8e-6*100:5.1f} %")

   300 rpm ->    20.5 k edges/s, CPU at 0.8 us each:   1.6 %
  3000 rpm ->   204.8 k edges/s, CPU at 0.8 us each:  16.4 %
  6000 rpm ->   409.6 k edges/s, CPU at 0.8 us each:  32.8 %
 12000 rpm ->   819.2 k edges/s, CPU at 0.8 us each:  65.5 %