Contact Debouncing

Momentary contact pushbuttons are inexpensive and commonly used mechanical switches that either make a connection or break a connection between its two terminals. Normally-open momentary contact pushbuttons make an electrical connection between two terminals when pushed or operated. A spring returns the button to the normal state and breaks the connection when released. The opposite action is true for normally-closed momentary contact pushbuttons. The simple pushbutton is more than adequate for many applications that have slow operating characteristics, such as ringing a door bell or sounding a horn.

If a pushbutton is connected to a microprocessor input pin, then we must consider how the contacts are actually operating. When a switch is pressed there is short period of time where oscillation of opening and closing the contact occurs due to the spring-mass characteristics of the mechanical contacts. This phenomenon is called contact bounce or switch bounce. The duration of the bounce period is random and can range from microseconds to hundreds of milliseconds. Signal conditioning circuits or computer firmware remove these unwanted signal characteristics. Figure 1 shows the typical signal seen by the microprocessor after the internal signal conditioning when the pushbutton switch is connected, as shown in Fig. 2. Depending on the speed at which the I/O pin is polled, it is possible that multiple events are detected instead of the single push operation. A search of the literature soon discloses that there are a plethora of digital and analog electronic circuits specifically designed to remove the multiple contact closures when the switch is activated and when it is de-activated. Equally numerous are the segments of hardware description language such as Verilog^®, VHDL, and microprocessor code to provide the signal conditioning using firmware. Fundamentally, the required signal conditioning is that of a low-pass filter. This signal conditioning suppresses the high frequencies generated by the contact bounce while retaining the low frequency signal generated by the press and release operations.

Buttons that make the connection between two terminals when pressed are called Push-ON switches and buttons that breaks the connection between two terminals are called push-OFF. Figures 2 through 5 show the possible connections for the push-ON and push-OFF switches to generate active high or active low signals. The pushbuttons on the chipKIT™Pro MX7 processor board are configured similarly to those circuits shown in Fig. 2.

A computer program can behave differently depending upon the duration of the contact bounce, the speed at which an I/O pin is polled, and exactly when the I/O pin is polled. Under unfavorable conditions the input can behave as though multiple events occurred when only one event is intended. One approach to avoid this problem is to poll the input pin multiple times over an appropriate period of time that extends beyond the expected contact bounce period. The logic value resulting from successive polling operations can be repeatedly compared until the I/O pin readings match. A flow diagram of computer code to implement this operation is shown in Fig. 6. While this approach has proven generally effective, it is by no means guaranteed to eliminate all of the effects of contact bounce on a computer program. More elaborate schemes must be used if the mechanical switch is to be employed in critical applications where spurious multiple contact closures cannot be tolerated.

There are two problems that must be addressed in the simple solution to contact bounce proposed in the flow diagram shown in Fig. 6. The initial problem to be addressed is what to specify as an appropriate delay period to filter out all but an acceptable number of multiple event detections due to contact bounce. Longer time delays are better, but if the delay is too long, the event can be missed due to a short button press (lack of signal persistence). The second problem is perceived response time. Ganssle states in his tutorial that 100 ms is within the human response time. A more appropriate computer response is to report the event immediately when the button state change is first detected but not report a button release until it occurs after the appropriate delay time. Such a solution is beyond the scope of this project but is addressed again in Project 5, Process Speed Control Using Interrupts, when we discuss the use of interrupts.