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 20, 2021
As it seems to be becoming a (bad) habit, This Week in CFD is presented here as Last Week in CFD. But that doesn't make the news any less relevant. Great article on wind tunnels because they go... [[ Click on the title to access the full blog on the Cadence Community si...
Sep 18, 2021
Projects with a steampunk look-and-feel incorporate retro-futuristic technology and aesthetics inspired by 19th-century industrial steam-powered machinery....
Sep 15, 2021
Learn how chiplets form the basis of multi-die HPC processor architectures, fueling modern HPC applications and scaling performance & power beyond Moore's Law. The post What's Driving the Demand for Chiplets? appeared first on From Silicon To Software....
Aug 5, 2021
Megh Computing's Video Analytics Solution (VAS) portfolio implements a flexible and scalable video analytics pipeline consisting of the following elements: Video Ingestion Video Transformation Object Detection and Inference Video Analytics Visualization   Because Megh's ...

featured video

Product Update: Complete DesignWare 400G/800G Ethernet IP

Sponsored by Synopsys

In this video product experts describe how designers can maximize the performance of their high-performance computing, AI and networking SoCs with Synopsys' complete DesignWare Ethernet 400G/800G IP solution, including MAC, PCS and PHY.

Click here for more information

featured paper

Seamlessly connect your world with 16 new wireless MCUs for the 2.4-GHz and Sub-1-GHz bands

Sponsored by Texas Instruments

Low-power wireless microcontroller (MCU) shipments are expected to double over the next four years to more than 4 billion units. This massive influx of MCUs will result in more opportunities for wireless connectivity than ever before, with growth across a wide range of applications and technologies. With the addition of 16 new wireless connectivity devices, we are empowering you to innovate, scale and accelerate the deployment of wireless connectivity – no matter what or how you are connecting.

Click to read more

featured chalk talk

AC Protection & Motor Control in HVAC Systems

Sponsored by Mouser Electronics and Littelfuse

The design of HVAC systems poses unique challenges for things like motor control and circuit protection. System performance and reliability are critical, and those come in part from choosing the right components for the job. In this episode of Chalk Talk, Amelia Dalton chats with Ryan Sheahen of Littelfuse about choosing the right components for your next HVAC design.

Click here for more information about Littelfuse AC Protection & Motor Control in HVAC Solutions