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?

13 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.

    1. Hi there — I just bounced over to read your article — very interesting indeed — however, if I were looking for extreme response speed, I would stick with the SPDT with SR Latch.

Leave a Reply

featured blogs
Mar 18, 2024
If you've already seen Vivarium, or if you watch it as a result of reading this blog, I'd love to hear what you think about it....
Mar 18, 2024
Innovation in the AI and supercomputing domains is proceeding at a rapid pace, with each new advancement heralding a future more tightly interwoven with the threads of intelligence and computation. Cadence, with the release of its Millennium Platform, co-optimized with NVIDIA...
Mar 18, 2024
Cloud-based EDA tools are critical to accelerating AI chip design and verification; see how NeuReality leveraged cloud-based chip emulation for their 7NR1 NAPU.The post NeuReality Accelerates 7nm AI Chip Tape-Out with Cloud-Based Emulation appeared first on Chip Design....

featured video

We are Altera. We are for the innovators.

Sponsored by Intel

Today we embark on an exciting journey as we transition to Altera, an Intel Company. In a world of endless opportunities and challenges, we are here to provide the flexibility needed by our ecosystem of customers and partners to pioneer and accelerate innovation. As we leap into the future, we are committed to providing easy-to-design and deploy leadership programmable solutions to innovators to unlock extraordinary possibilities for everyone on the planet.

To learn more about Altera visit: http://intel.com/altera

featured paper

Reduce 3D IC design complexity with early package assembly verification

Sponsored by Siemens Digital Industries Software

Uncover the unique challenges, along with the latest Calibre verification solutions, for 3D IC design in this new technical paper. As 2.5D and 3D ICs redefine the possibilities of semiconductor design, discover how Siemens is leading the way in verifying complex multi-dimensional systems, while shifting verification left to do so earlier in the design process.

Click here to read more

featured chalk talk

Nexperia Energy Harvesting Solutions
Sponsored by Mouser Electronics and Nexperia
Energy harvesting is a great way to ensure a sustainable future of electronics by eliminating batteries and e-waste. In this episode of Chalk Talk, Amelia Dalton and Rodrigo Mesquita from Nexperia explore the process of designing in energy harvesting and why Nexperia’s inductor-less PMICs are an energy harvesting game changer for wearable technology, sensor-based applications, and more!
May 9, 2023
36,886 views