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.
Best Answer
I would offer a Conditional Yes.
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
1in 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.