When you have more than a dozen switches to debounce, it is best to opt for a hardware solution unless you're making something in the 100k+ quantities.

We've used MAX7370 chip for keyboard applications. Comes with built-in debounce capabilities along with ESD protection, low quiescent current and interrupt-based signal to the MCU. It is expensive but well worth the hassle - it can handle up to 64 switches and saves you the pain of GPIO nightmare with custom matrix. In addition, it comes with a hardware memory buffer so you could do an n-key roll over. I've built stuff that I can mash with my palm - like jamming on a couple of dozen switches at the same time and this chip handles it all. Flawlessly.

If you are doing this for a Linux platform, there's actually a gpio matrix keypad driver that works really well. The driver shows up as a regular keyboard input device that can interface with any program that knows how to read /dev/input things.

I do not like the idea of sending an interrupt and cause a havoc on OS side every time two metal plates bounce off each other.

I can understand this when this happens to a device that is created to monitor the switch (switch matrix controller, keyboard controller, etc.) but when this happens to a machine that may have something more important to do it feels at the very least inelegant.

Agreed, just as encapsulation/abstraction is an important and indispensible concept in software engineering, it is also equally if not more critical in hardware applications. For most electronics, there is usually an IC that can solve a problem better than you can develop, often cheaper. 25 discrete components can be encapsulated by a single IC sometimes (with a couple of bypass caps).

> For most devices it is enough to just probe the switch periodically.

No, no, no, please don't. Almost all appliances I use ignore an estimated 60% of my usual button presses because they're polling in intervals just long enough to not recognise anything, and I absolutely hate it.

I always have to hold it down for a bit to make sure my input isn't just ignored. My laptop's power switch has this issue just like the washing machine, the dish washer and pretty much everything else that's not a PC keyboard, and it's one of the most infuriating UI issues I encounter every day, beside inactive text input fields with blinking cursors or selected text.

> No, no, no, please don't. Almost all appliances I use ignore an estimated 60% of my usual button presses because they're polling in intervals just long enough to not recognise anything, and I absolutely hate it.

That's just sloppy design. "Periodically" has meant "every 20 milliseconds" for projects I've shipped in the past. Anything shorter than 100 ms or so should be imperceptible.

Part of the problem you're likely seeing is due to the rise of capacitive touch "buttons", which are terrible in so many ways. But, alas, they are cheap and give a smooth front face, so designers and product managers love them....

(About the only time they're actually a good solution is when you need a completely sealed button.)

Power buttons, like on a PC or washing machine, often require being held as a means of preventing accidental activation.

I don't mean just power buttons. When I said almost every button not on a PC keyboard I meant it. On the washing machine every single button has to be held almost half a second or it won't do anything. It's super frustrating. But of course it's possible to mess this up the other way too - one of my devices reacts quick to button presses, but you have to wait about half a second until it will react to the next press.

I believe that in some applications this is by design

You don't want your washing machine to start just because you bumped into the button. Give it a good press and it's ok. (Same with the mechanical sensitivity of the buttons itself, they're not the same as your phone touchscreen let's put it this way)

There's no need for debouncing to introduce latency under normal circumstances. React immediately to state changes, and whenever you observe a state change begin temporarily ignoring further state changes for long enough for the bouncing to settle. The only added latency is on the falling edge of extremely short presses (or rising edge of extremely short releases), which in practice doesn't happen because of limited speed of the human hand. But note that latency-adding debouncing methods double as noise filters, which this technique does not, so you might want to add a bit of noise filtering (and associated latency) too.

I think of this as "non causal debouncing". You debounce before the event happens.

> For most devices it is enough to just probe the switch periodically.

Often you want to use interrupts instead of polling - well again, you can just ignore subsequent interrupts if they are within too short of an interval.

Fortunately on many MCUs you can just enable hardware debounce.

> Often you want to use interrupts instead of polling - well again, you can just ignore subsequent interrupts if they are within too short of an interval.

And you are really screwed if you have to do it with an extremely simple, and cheap IC, like 4 bit micros, because their CPU power may well be not enough for that, especially if they are to control something real time.

This is exactly why super cheap electronics uses conductive rubber buttons. Conductive rubber buttons don't bounce.

Conductive rubber buttons absolutely do bounce (though I presume that was a joke).

??? for as long as I remember, all and everybody was using them exactly for that reason. Slow raising edge can be considered a bounce by some logic, but that is easily fixable by Schmitt triggers

Thanks, that's interesting. I suppose they specifically choose contacts with a high resistance.