Hardware debouncing
I’ve been playing with debouncing signals that come in from mechanical switches, because I’m building a timer that’ll detect when a garage door has been opened, and close it again 10 minutes later, so several friends of mine won’t end up coming home to open, and emptied-out, garages. It’s possible to debounce signals in software. Here’s a whole bunch of stuff on software debouncing, concentrating on interrupt-driven intelligent debounce code, that doesn’t monopolize the processor with polling or delays. Good stuff, but somewhat complicated. I like hardware solutions because they give me more code space.
This page details a hardware debounce circuit. I’d come up with pretty much the same design, fooling around on my own. A lot of people omit the diode, and while it still usually works, I’ve run into testing situations where having a diode in there made a lot of difference.
First I messed about with switches to see how bad they were. I’d like some idea of the worst-case switch noise, for sizing the R/C filter on the front of the schmitt trigger.
So, here are some screen captures of some lousy switches.
A standard cheap 110v wall switch:

That’s about 200 microseconds of noise.
I grabbed a nice DPDT rocker switch, with a lighted switch, that I’d bought as a backup for the one I stuck in my girlfriend’s car, the day I surreptitiously swapped her horn for one that goes “a-WOO-GAH!” so that when she tires of the awoogah horn she can switch back to the boring little beep-beep. It works great for that purpose. It doesn’t work so well for interfacing to microcontrollers, because here’s how it looks:

Note the time stamp in the bottom right hand corner: each division is 500 microseconds, so this switch is still thrashing about at 5 milliseconds. Thankfully this is my worst-case scenario, of the switches I tried.
On the other end of the spectrum, here’s a cheap tactile switch.

Again, note the time: this switch has grounded in 200 *nanoseconds* with no excursions whatsoever. So choose your switch carefully and you might not even need any debouncing.
However, you’re not going to trust that, right?
So let’s look at an actual use case. I’m working with a SPDT toggle switch. For the sake of completeness I checked the bounce when I turned it on, and when I turned it off. They’re not anything like the same.
Here’s the signal we’re probably looking for: 5V switching to ground.

That could stand some debouncing.
On the other hand, here’s what happens when the switch opens, and the signal runs back up to 5V.

That could run as is.
But I’m not willing to rely on that. Maybe next time it’ll have junk in the contacts.
So I put the hardware debouncer between the switch and the scope. The debouncer has an RC filter on the front, and then a trigger. The filter smooths out a lot of the junk we see in the signal, and the trigger digitizes it, choosing whether it’s a 0 or a 1.
Here’s a screenshot of the same timeframe as the previous two shots, as the switch opens.

The RC filter slows down the voltage rise, and smooths it out. Here’s a shot with the time cranked out from microseconds to milliseconds.

And finally, the switch closing, with the debounce circuit.

That looks pretty good to me: my back-of-envelope calculations say it should be able to debounce noise out to about 50 milliseconds. Now, the flip side of that is that it can’t see any *intentional* signals that have a shorter duration than that, so there’s a bandwidth limit, and I need to choose my RC filter pair to match the signal I’m trying to condition.