feature article
Subscribe Now

Ultimate Guide to Switch Debounce (Part 1)

They taught me a lot of things at university. Unfortunately, they neglected to mention the topic of switch bounce. If you are a practicing engineer working with electronic systems, you will almost certainly have run into this problem. If you are new to the field, you can be assured that the delights of switch bounce are lurking out there waiting for an opportunity to bid you a cheery “Hello!” Be afraid; be very afraid.

If they think about it at all, most non-engineers visualize the operation of a switch as being similar to dropping a chunk of Play-Doh on a wooden desk. When the Play-Doh lands, it goes “splat” and stays where it is. In reality, operating a switch is more like dropping a ping-pong ball onto the desk. In this case, the ball will bounce multiple times before eventually settling down. Similarly, when we operate a switch, it also bounces one or more times before coming to rest in its new state.

This switch bounce occurs both when the switch is closed and when it opens again. It also occurs in toggle switches, rocker switches, pushbutton switches, and so-forth — pretty much everything apart from the switches most of us never use anyway, like mercury tilt switches, for example.

In the case of a light switch on the wall, we don’t notice the fact that it bounces because everything occurs too fast for it to register on our eyes and in our brains. It’s a different story when the switch is connected to a microcontroller (MCU) that can sample its inputs millions of times each second. In this case, the MCU may see the switch being toggled as comprising multiple events. If you were in charge of pressing a pushbutton every time someone entered a room for example, then the MCU might count each press as comprising anywhere from one to twenty (or more) events.

Just to increase the fun and frivolity, each switch is different. This not only by type, although that may play a factor; switches of the same type can behave in contrary ways. Even worse, an individual switch may vary its characteristics depending on the temperature, humidity, time of day, direction of the prevailing wind, and the color of your plaid polyester golf trousers.

If a switch is connected to some safety-critical or mission-critical system, and the system’s designers haven’t adequately addressed its switch-bounce characteristics, then the chances are that someone, sometime, is going to have a “very bad hair day.”

If a system can be negatively affected by switch bounce, then someone is going to have to deal with the issue, either in hardware or in software. Now, if you aren’t a designer working in the trenches (perhaps you are a manager, bless your little cotton socks), you may mistakenly assume that, since we are all aware this is an issue, we are also all cognizant of the answer to the problem. Would that it were so; unfortunately, there is no “one size fits all” solution.

The way things used to work in the not-so-distant past is that junior engineers were instructed as to the switch-bounce solution(s) favored by their more senior colleagues. In turn, those fonts of knowledge were instructed by their mentors, and so on and so forth deep into the mists of time. As a result, there are now so many solutions scattered around the internet — where most young engineers now go to satiate their craving for knowledge — that it makes your head spin. On the bright side, some of these offerings actually work; on the downside, their working may be due to chance rather than design.

How bad is this problem? It’s rampant. Have you ever pressed the Up or Down channel selector on a TV controller, only to have it skip through multiple channels? If so, the controller’s designers probably didn’t account for switch bounce as well as they thought they had. Just a few days ago as I pen these words, I was discussing this issue with the legendary embedded guru Jack Ganssle, who said, “I agree about people not knowing this stuff. In fact, I own a small FM transmitter that is hard to turn off because its power switch bounces so much.”

I asked Jack to elucidate (it’s OK, he’s a professional), and he replied as follows: “We live pretty far out in the country, and my hearing protectors, which have an FM receiver, can’t get Baltimore’s classical station. In the olden days, a half-dozen vacuum tube radio would be all one would need to listen to the radio. Instead, I now use an old iPhone that streams the station. The phone is plugged into a 100 mW FM transmitter that broadcasts on an empty frequency to my hearing protectors when I’m using noisy tools (tractor, sawmill, chainsaw, etc.). So, instead of a half-dozen vacuum tubes, I’m now using the 100 billion or so transistors in the iPhone! The transmitter itself is a cheap Chinese device. When I press the power button to turn it off, half the time it goes off and then comes on again — a classic case of switch bounce.”

Just What is a Switch?

Before we proceed, we should perhaps note that, in the context of electrical engineering, the term “switch” refers to a component that can “make” or “break” an electrical circuit, thereby interrupting the current or diverting it from one conductor to another.

We should also note that there is a mind-boggling variety of switch types, including toggle switches, rocker switches, slide/slider switches, rotary switches, pushbutton switches, tactile switches, micro and limit switches, knife switches, magnetic switches, reed switches, mercury switches, smart switches, and… the list goes on (you can peruse and ponder my Switch Types column to see images and discover more).

Hardware vs. Software

As we alluded to earlier, there is a wide range of solutions one can use to address the switch bounce problem. One approach is to pre-process the switch signal in hardware so as to pass a “clean” (debounced) signal to the computer. An alternative technique is to feed the “dirty” (bouncing) signal from the switch directly into the computer, and to “clean it up” (remove the bouncing) in software.

Prior to the introduction of the microprocessor circa the 1970s, there were relatively few computers around, and these were typically of the mainframe (“big iron”) variety. Just renting a mainframe computer circa the mid-1960s could cost tens of thousands of dollars a month (goodness knows what buying one would cost). Thus, at that time, price was not an issue with regard to a solution to debounce the switches; what was an issue was consuming precious memory and clock cycles.

Although the mainframes of the 1960s were physically large, they were extremely limited in terms of memory and performance (at least, they were by today’s standards). For example, the IBM System/360 Model 30, which was introduced in 1964, came equipped with only 8 to 64KB of memory and could perform only 34,500 instructions per second. Not surprisingly, programmers at that time didn’t want to waste any of their precious memory or instruction cycles doing something so mundane as debouncing switches (the situation wasn’t helped by the fact that the programmers probably weren’t aware of switch bounce in the first place).

The solution of choice, the crème de la crème (as it were) of hardware debouncing solutions was to use… but no! There are so many tasty tidbits of trivia and savory nuggets of knowledge pertaining to the myriad hardware and software solutions available that we will save them until my next column. In the meantime, do you have any stories you’d care to share regarding problems caused by bouncing switches?

11 thoughts on “Ultimate Guide to Switch Debounce (Part 1)”

  1. Max,
    As you likely recall, there was some great discussion regarding this subject on the late Programmable Planet website, before it was so ruthlessly destroyed by the Vogon contingent at UBM & Xilinx to make way for an interstellar billboard, without bothering to create a read-only public archive…
    With that whinge (mostly) out of the way, my favorite technique (as I had once described so eloquently on aforementioned website, before those posts were “lost in time, like tears in rain” ) for FPGA switch input debouncing is a minimal hardware circuit of about a half dozen flip-flops per input to debounce, using a common timebase counter shared by all inputs, that performs the debounce function with a glitch-detecting sampler like the logic analyzers of yore used at low sample rates. If one has, say, 50 inputs to debounce, this approach requires much less hardware than does a counter-per-input-pin debouncer.
    Example VHDL debouncer and testbench are here:
    https://github.com/brimdavis/yard-1/tree/master/hdl/common/debounce

    -Brian

    1. Hi Brian — thanks for sharing — I’m sorry that I only just now saw your comment — I still feel bad about All Programmable Planet (APP) — we had some great content there — I really think Xilinx dropped the ball on that one — I think that, by now, APP could have grown to be the “go to” site for programmable logic.

Leave a Reply

featured blogs
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through hole products, a single or double row surface mount with a larger center-line rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and conne...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...
Oct 23, 2020
Any suggestions for a 4x4 keypad in which the keys aren'€™t wobbly and you don'€™t have to strike a key dead center for it to make contact?...
Oct 23, 2020
At 11:10am Korean time this morning, Cadence's Elias Fallon delivered one of the keynotes at ISOCC (International System On Chip Conference). It was titled EDA and Machine Learning: The Next Leap... [[ Click on the title to access the full blog on the Cadence Community ...

featured video

Demo: Low-Power Machine Learning Inference with DesignWare ARC EM9D Processor IP

Sponsored by Synopsys

Applications that require sensing on a continuous basis are always on and often battery operated. In this video, the low-power ARC EM9D Processors run a handwriting character recognition neural network graph to infer the letter that is written.

Click here for more information about DesignWare ARC EM9D / EM11D Processors

featured Paper

New package technology improves EMI and thermal performance with smaller solution size

Sponsored by Texas Instruments

Power supply designers have a new tool in their effort to achieve balance between efficiency, size, and thermal performance with DC/DC power modules. The Enhanced HotRod™ QFN package technology from Texas Instruments enables engineers to address design challenges with an easy-to-use footprint that resembles a standard QFN. This new package type combines the advantages of flip-chip-on-lead with the improved thermal performance presented by a large thermal die attach pad (DAP).

Click here to download the whitepaper

Featured Chalk Talk

uPOL Technology

Sponsored by Mouser Electronics and TDK

Power modules are a superior solution for many system designs. Their small form factor, high efficiency, ease of design-in, and solid reliability make them a great solution in a wide range of applications. In this episode of Chalk Talk, Amelia Dalton chats with Tony Ochoa of TDK about the new uPOL family of power modules and how they can deliver the power in your next design.

Click here for more information about TDK FS1406 µPOL™ DC-DC Power Modules