Debouncing Buttons and Switches

The robust approach is to stop reacting to edges and instead look at the input at a steady rate, for example every millisecond, then decide what the switch is doing from its recent history. Two families of decision rule exist:

• Defer. Report a change only after the input has stayed at the new level for the debounce time. Bounces reset the wait. Robust against bounce and against short noise spikes, but every event is delayed by at least the debounce time.
• Eager. Report the first change immediately, then ignore the input for the debounce time. No delay, but a single noise spike is reported as a press.

↑ This step uses the figure at the top of the page.

For eager debouncing the debounce time must outlast the whole bounce; for defer it must outlast the longest quiet gap inside the bounce, which is shorter, but a margin is wise either way; 5 ms is a common default (QMK’s keyboards and Linux’s gpio-keys driver both use it), while Arduino’s teaching example uses a generous 50 ms. Measure your switch: in Ganssle’s tests of 18 switches the bounce averaged about 1.6 ms (two outliers excluded), the worst of the rest reached 6.2 ms, and one outlier bounced for 157 ms on opening.

The version with timestamps, called every millisecond or simply every pass of the main loop:

typedef struct { bool stable, last_raw; uint32_t changed_ms; } button_t;

bool button_update(button_t *b, bool raw, uint32_t now_ms) {   /* true on a new stable state */
    if (raw != b->last_raw) { b->last_raw = raw; b->changed_ms = now_ms; }
    if (raw != b->stable && (uint32_t)(now_ms - b->changed_ms) >= DEBOUNCE_MS) {
        b->stable = raw;
        return true;
    }
    return false;
}

Timestamps make the debounce time independent of how often the function is called (the call interval must still be well below the debounce time, or the decision rests on only a sample or two), and the unsigned subtraction survives counter wrap as long as the millisecond counter wraps at 2³² (unit 6, lesson 6). Initialise stable and last_raw from a first reading of the pin, or an idle-high button reports a spurious change at start-up. Long press and double click are the same idea one level up: timestamps of stable-state changes.

Configuring an edge interrupt and counting in the handler looks efficient, but a bouncing switch can fire dozens of interrupts in a few milliseconds, each one taking CPU time and pushing other interrupts later, and the handler still has to debounce. Better patterns: use the interrupt only to wake the chip or to start the sampling, then disable it until the debounced state has settled; or simply sample from a periodic timer tick.

A switch bounces for 3 ms; the loop samples every 1 ms with a 5 ms defer debounce. The last bounce ends 3 ms after the first contact, and the state is accepted 5 ms after that:

rounded to the sampling grid. For a user, 8 ms is imperceptible. For a switch that detects the end of a mechanical travel, it may matter, which is where eager debouncing, or an eager press with a deferred release (QMK’s asym_eager_defer_pk), is used.