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
Sep 21, 2023
Wireless communication in workplace wearables protects and boosts the occupational safety and productivity of industrial workers and front-line teams....
Sep 21, 2023
Labforge is a Waterloo, Ontario-based company that designs, builds, and manufactures smart cameras used in industrial automation and defense applications. By bringing artificial intelligence (AI) into their vision systems with Cadence , they can automate tasks that are diffic...
Sep 21, 2023
At Qualcomm AI Research, we are working on applications of generative modelling to embodied AI and robotics, in order to enable more capabilities in robotics....
Sep 21, 2023
Not knowing all the stuff I don't know didn't come easy. I've had to read a lot of books to get where I am....
Sep 21, 2023
See how we're accelerating the multi-die system chip design flow with partner Samsung Foundry, making it easier to meet PPA and time-to-market goals.The post Samsung Foundry and Synopsys Accelerate Multi-Die System Design appeared first on Chip Design....

featured video

TDK PowerHap Piezo Actuators for Ideal Haptic Feedback

Sponsored by TDK

The PowerHap product line features high acceleration and large forces in a very compact design, coupled with a short response time. TDK’s piezo actuators also offers good sensing functionality by using the inverse piezo effect. Typical applications for the include automotive displays, smartphones and tablet.

Click here for more information about PowerHap Piezo Actuators

featured paper

An Automated Method for Adding Resiliency to Mission-Critical SoC Designs

Sponsored by Synopsys

Adding safety measures to SoC designs in the form of radiation-hardened elements or redundancy is essential in making mission-critical applications in the A&D, cloud, automotive, robotics, medical, and IoT industries more resilient against random hardware failures that occur. This paper discusses the automated process of implementing the safety mechanisms/measures (SM) in the design to make them more resilient and analyze their effectiveness from design inception to the final product.

Click here to read more

featured chalk talk

Designing with GaN? Ask the Right Questions about Reliability
As demands for high-performance and low-cost power conversion increases, gallium nitride offers several intriguing benefits for next generation power supply design. In this episode of Chalk Talk, Amelia Dalton and Sandeep Bahl from Texas Instruments investigate the what, why and how of gallium nitride power technology. They take a closer look at the component level and in-system reliability for TI’s gallium nitride power solutions and why GaN might just be the perfect solution for your next power supply design.
Oct 4, 2022
40,479 views