Hacker News Reader

Comment by poyu | Hacker News Reader

Debounce is an interesting topic[0], I tend to use hardware debounce whenever possible on my own projects.

[0]: https://hackaday.com/2010/11/09/debounce-code-one-post-to-ru...

There's some good info here if anyone is interested: http://www.ganssle.com/debouncing.htm

Don't accept a keypress if the same key was previously pressed less than x milliseconds ago. What else is there to know about debouncing?

The problem is that you're dealing with an analogue signal. The gold standard for debouncing because of that is a low-pass filter, which is implementable by a resistor and capacitor, and way more reliable (and responsive) than any software solution.

Can you describe a case in which rejecting a duplicate keypress that arrives within a specified number of milliseconds is ineffective, unreliable, or even suboptimal?

A lowpass filter is an empirical hack, not a gold standard. It has multiple disadvantages; rather than being "responsive," it adds latency to the initial input for no good reason, and it affects both rising and falling edges equally, again for no good reason. It also requires the addition of unnecessary physical components.

What is x? Is it related to human capability?

Key bounce takes place at timescales far shorter than human reaction times. Typically you'd base the interval on the mechanical characteristics of the keypad.

For instance, taking a look with a scope, if you observe that the signal stops bouncing after 3 milliseconds, it would be pretty safe to accept duplicate keypresses with a 10-ms guard interval.

You'd have to have two intervals though, one for on, one for off. It bounces both ways. Hardware is more elegant but obviously the tradeoffs depend on what you're implementing.

It bounces both ways but as long as you don't accept another keypress action (up or down) immediately after the first, you're fine.

You're fine either way. You either have to poll, or use interrupts. If you are polling, you don't need to debounce the circuit. If you use interrupts, you're going to have a very bad time if you don't. Interrupts are much more efficient. Polling is wasteful.

I don't see why interrupts wouldn't work without hardware debouncing.

$2 micros are many MHz. All it has to do is save/compare one timestamp per interrupt.

So lets do some back-of-the-napkin calculations and say it takes 1us to store/compare the timestamp, a switch transitions 50 times per press on each change of state, and a person is typing at 100wpm (lets say 600cpm = 10cps).

I think these are pretty conservative numbers, 50 bounces sounds like a pretty crappy switch to me.

So 1000 transitions per second which would take 1ms, which means 1/1000th of the time is spent servicing the interrupts.

It's not going to cause a problem unless the coding is very inefficient.

Since your ISR does nothing but record a timestamp (right...?) you are not going to have a "very bad time."

Although in many cases polling is fine as well.

Reply on news.ycombinator.com