Content area
Full Text
After last month's look at the Embedded Systems Conference we're back to the surprisingly deep subject of debouncing switch inputs. But first, a mea culpa for mixing up formulas in May's column ("Solving Switch Bounce Problems," May 2004, on pages 46 and 48). The first and second formulas were accidentally swapped. To see the corrected version, go to www.embedded.com/showArticle.jhtml?art icleID=18902552.
Software debounce routines range from some quite simple approaches to sophisticated algorithms that handle multiple switches in parallel. Many developers create solutions without completely understanding the problem. Sure, contacts rebound against each other. But the environment itself can induce all sorts of short transients that mask themselves as switch transitions. Called EMI (electromagnetic interference), these bits of nastiness come from energy coupled into our circuits from wires running to the external world or even from static electricity induced by feet shuffling across a dry carpet. Happily EMI and contact whacking can be cured by a decent debounce routine, but both factors do affect the design of the code.
Consider the simplest of all debouncing strategies: read the switch once every 500ms or so, and set a flag indicating the input's state. No reasonable switch will bounce that long. A read during the initial bounce period returns a zero or a one indicating the switch's instantaneous state. No matter how we interpret the data (in other words, switch on or off) the result is meaningful. The slow read rate keeps the routine from deducing that bounces are multiple switch closures. One downside, though, is slow response. If your user won't hit buttons at a high rate this is probably fine. A fast typist, though, can generate 100 words per minute or almost 10 characters per second. A rotating mechanical encoder could generate even faster transitions.
No EMI protection is inherent in such a simple approach. An application handling contacts plated onto the printed circuit board is probably safe from rogue noise spikes, but one that reads from signals cabled onto the board needs more sophisticated software since a single glitch might look like a contact transition.
It's tempting to read the input a couple of times each pass through the 500ms loop and look for a stable signal. That'll reject much or maybe all of...