← Back to context

Comment by Findecanor

6 months ago

I agree that this is a bad analogy.

I've programmed my own keyboards, mice and game controllers. If you want the fastest response time then you'd make debouncing be asymmetric: report press ("Make") on the first leading edge, and don't report release ("Break") until the signal has been stable for n ms after a trailing edge. That is the opposite of what's done in the blog article.

Having a delay on the leading edge is for electrically noisy environments, such as among electric motors and a long wire from the switch to the MCU, where you could potentially get spurious signals that are not from a key press. Debouncing could also be done in hardware without delay, if you have a three-pole switch and an electronic latch.

A better analogy would perhaps be "Event Compression": coalescing multiple consecutive events into one, used when producer and consumer are asynchronous. Better but not perfect.

Debouncing is established terminology in UI and other event-handling stuff at this point, and has been for a decade. It's a bit too late to complain. Language evolves and not all new uses of words are good analogies.