© 2004 The Ganssle Group. This work may be used by individuals and companies, but all publication rights reserved A Guide to Debouncing August 2004 Rev 1: April, 2006 Rev 2: April, 2007 Rev 3: June, 2008 Jack G. Ganssle [email protected] The Ganssle Group PO Box 38346 Baltimore, MD 21231 (410) 504-6660 fax (647) 439-1454Page 1 A Guide to Debouncing The beer warms a bit as you pound the remote control. Again and again, temper fraying, you click the “channel up” key until the TV finally rewards your efforts. But it turns out channel 345 is playing Jeopardy so you again wave the remote in the general direction of the set and continue fiddling with the buttons. Some remotes work astonishingly well, even when you bounce the beam off three walls before it impinges on the TV’s IR detector. Others don’t. One vendor told me reliability simply isn’t important as users will subconsciously hit the button again and again till the channel changes. When a single remote press causes the tube to jump two channels, we developers know lousy debounce code is at fault. The FM radio on my sailboat has a tuning button that advances too far when I hit it hard. The usual suspect: bounce. When the contacts of any mechanical switch bang together they rebound a bit before settling, causing bounce. Debouncing, of course, is the process of removing the bounces, of converting the brutish realities of the analog world into pristine ones and zeros. Both hardware and software solutions exist, though by far the most common are those done in a snippet of code. Surf the net to sample various approaches to debouncing. Most are pretty lame. Few are based on experimental bounce parameters. A medley of anecdotal tales passed around the newsgroups substitute for empirical evidence. Ask most developers about the characteristics of a bounce and they’ll toss out a guess at a max bounce time. But there’s an awful lot going on during the bounce. How can we build an effective bounce filter, in hardware or software, unless we understand the entire event? During that time a long and complex string of binary bits is hitting our code. What are the characteristics of that data? We’re writing functions that process an utterly mysterious and unknown input string. That’s hardly the right way to build reliable code. The Data So I ran some experiments. I pulled some old switches out of my junk box. 20 bucks at the ever-annoying local Radio Shack yielded more (have you noticed that Radio Shack has fewer and fewer components? It’s getting hard to buy a lousy NPN transistor there). Baynesville Electronics (http://www.baynesvilleelectronics.com), Baltimore’s best electronics store, proved a switch treasure trove. Eventually I had 18 very different kinds of switches. My desktop PC always has a little $49 MSP430 (TI’s greatly underrated 16 bit microprocessor) development board attached, with IAR’s toolchain installed. It’s a matterPage 2 A Guide to Debouncing of seconds to pop a little code into the board and run experiments. Initially I’d planned to connect each switch to an MSP430 input and have firmware read and report bounce parameters. A bit of playing around with the mixed signal scope (MSO) showed this to be an unwise approach. Many of the switches exhibited quite wild and unexpected behavior. Bounces of under 100 nsec were common (more on this later). No reasonable micro could reliably capture these sorts of transitions, so I abandoned that plan and instead used the scope, connecting both analog and digital channels to the switch. This let me see what was going on in the analog domain, and how a computer would interpret the data. A 5 volt supply and 1k pull-up completed the test jig. If a sub-100 nsec transition won’t be captured by a computer why worry about it? Unfortunately, even a very short signal will toggle the logic once in a while. Tie it to an interrupt and the likelihood increases. Those transitions, though very short, will occasionally pervert the debounce routine. For the sake of the experiment we need to see them. I tested the trigger switches from an old cheap game-playing joystick (the three yellow ones in the picture), the left mouse button from an ancient Compaq computer (on PCB in upper left corner), toggle switches, pushbuttons, and slide switches. Some were chassis mount, others were to be soldered directly onto circuit boards. Switches tested. The upper left is switch A, with B to its right, working to E (in red), and then F below A, etc. I gave up regular oscilloscopes long ago; now my Agilent 54645D MSO is a trusty assistant that peers deep into electronic systems. An MSO is both logic analyzer and o-scope, all in one. Trigger from either an analog channel or a digital pattern to start the trace. The MSO shows, like no other instrument, the relationship between the real world and our digital instantiation of it.Page 3 A Guide to Debouncing I pressed each switch 300 times, logging the min and max amount of bouncing for both closing and opening of the contacts. Talk about mind-numbingly boring! I logged every individual bounce time for each actuation into a spreadsheet for half the switches till my eyes glazed over and gentle wife wondered aloud if I was getting some sort of Pavlovian reward. The results were interesting. Bounce Stats So how long do switches bounce for? The short answer: sometimes a lot, sometimes not at all. Only two switches exhibited bounces exceeding 6200 μsec. Switch E, what seemed like a nice red pushbutton, had a worst case bounce when it opened of 157 msec – almost a 1/6 of a second! Yuk. Yet it never exceeded a 20 μsec bounce when closed. Go figure. Another switch took 11.3 msec to completely close one time; other actuations were all under 10 msec. Toss out those two samples and the other 16 switches exhibited an average 1557 μsec of bouncing, with, as I said, a max of 6200 μsec. Not bad at all. Seven of the switches consistently bounced much longer when closed than when opened. I was amazed to find that for most of the switches many bounces on opening lasted for less than 1 μsec – that’s right, less than a millionth of a second.