All of the software debouncing routines I've seen involve waiting until some number of sequential reads of a signal return 0 or 1. That makes sense, of course. But it means there's an inevitable compromise between robustness and latency. The more readings you demand to accept a change in level, the longer the response time.

It seems like a simple alternative would be to simply ignore the input readings for a certain amount of time after an edge. If the switch had been reading 0, and then a single poll returns a 1, then interpret this as a logical 1 for the duration of the expected bounce period. Likewise when transitioning from 1 to 0.

Obviously this would still limit the maximum input rate. But it would also bring the latency for a single button press down to nearly zero, even for extremely long debounce times.

Are there problems with this approach? It seems like an obvious approach to software debouncing, so I'm surprised it doesn't seem to be used.

3 Answers
3

Your suggested approach assumes nice, clean signals. If you were to pick up any noise on the trace you would run the risk of acting on faulty information.
For example: If there was a voltage spike(s) on the signal when you polled the input, you would read a 1 in your program. In your proposal, you would assume that the switch had be pressed (when it really had not) until you polled the input again after your "debounce interval". At which point you find out that, oh wait just kidding, the switch really wasn't pressed.
So, for the duration of the "debounce interval" you are continuing through your program presumably acting on the faulty information that the switch has been pressed.

Basically it comes down to:What are you trying to protect against?What's the worst that can happen if you're wrong?

If you were building a battery-operated kid's game in a plastic box, there probably won't be much electrical noise to screw up your inputs; so your simplified debouncing would be just fine.
However, if this part of life-support device in a hospital... you might want to go with a little more robust input debouncing logic.

Do you have a reference for the statement that bounce is limited to less than 5 ms? My recollection is that it can be much longer.
–
Joe HassFeb 3 '14 at 21:18

On small switches (eg. tact switches) from generic Asian suppliers, my experience is that it is sufficient. I looked up three with max specs, two said < 1msec, one said < 3msec on/8msec off. 5msec is the guarantee on the mechanical encoders we use. I'm sure if you tried you could find a counter-example, for example a big snap-action switch, but on such as switch a 20msec delay is even less noticeable than on a "keypad" type switch. "One size fits all" Maxim debouncers use 20msec. If it starts to creep up to 50msec debounce delay, it becomes noticeable on a keypad.
–
Spehro PefhanyFeb 3 '14 at 21:35