The debouncing of switches (keypads or buttons) is a topic one student recently told me wasn't being taught in his class - his instructor didn't know what it was.

Here's a description of De-Bounce:

Switches are designed for Human-time more than for the fast world of micros. If you look at a switch making or breaking contact on a storage scope, you'll see that the electrical levels toggle back and forth many times for a period of roughly 40 to 60us before they stabilize, nothing like the digital logic transitions you are used to. A micro is so fast it could read the switch many times during this "bouncing" and wrongly interpret it as many separate keypresses.

The technique for handling this is known as "De-bouncing" in the USA because it removes the bouncing electrical signal described above. If anyone has other terms for the same technique, I'd be interested to hear them.

Usually the debouncing software technique monitors electrically the PHYSICAL state of the simple on/off switch and use it to create a LOGICAL state which internal software routines monitor instead of the port. The debouncing software is best used as a background task if you're esperienced in using interrupts, but it can be done in foreground. It can even be "inferred" in software by situational choices as we did recently in a memory game discussed in the forum and email.

The technique I use most often monitors the switch at a rate at least ten times the debounce duration. In memory I maintain the following variables:

(1) A bit holding the last polled state of the PHYSICAL switch. This is used as a memory to decide if the signal is stable or changing.

(2) A bit holding the result of the debounce routine. This is the LOGICAL image that internal routines use to make decisions upon the switch.

(3) A byte counter value used to count to a threshold so that the debounce routine will know when the switch has stopped bouncing and has become stable for about 40 to 60us. (everytime the physical switch changes state, this counter is reloaded whether finshed or not). When the byte counter reaches a threshold, is is time to update the LOGICAL image of the switch because the count assures that the switch has become stable in that state.

Debounce Polling Routine:
Using a count-down approach

(1) Check the current state through the port and see if its different from the previous PHYSICAL level saved during the prior polling. If its the SAME level, then:

(1a) If the counter is ZERO (already debounced) then the switch is still stable. RETURN.

(1b) If the counter is NON-zero, decrement it and test for zero. If its still non-zero, RETURN. If its now zero then the signal has been stable long enough to be past the bounceing edge so update the internal LOGICAL image of the switch to the current PHYSICAL image. RETURN.

(2) If the current level of the port is different from the prior polled value, then write the new value over that PHYSICAL image. Next reload the debounce counter with its starting value (it counts down). RETURN.


That's all there is to it. Usually you don't have but one debounce routine to support all the switches. There are various ways to accomplish that. Other modifications are required to support several keys being pressed "somewhat" simultaneously.


The way I implement it is too complex for the new programmers. My preference is to put the key debouncer into my background threaded tasker. The tasker is brought up periodically by a timer interrupt and it uses a dynamic software thread to process events during its interrupt slot. All background tasks have a link in this thread and they independently control their rate and entrypoints. A task like a debouncer, can keep track of its own state by changing its link in the tasker thread at its completion of its run. In other words, it tells the tasker via a thread entry, where in its flowchart to start when the tasker fires next time.

Its real cool, and because the tasker is part of my business, I won't discuss that topic in greater detail. :-)

-Jay C. Box