Clive "Max" Maxfield (www.clivemaxfield.com/coolbeans) received his B.Sc. in Control Engineering in 1980 from Sheffield Polytechnic (now Sheffield Hallam University), England.
Max began his career as a designer of central processing units (CPUs) for mainframe computers. Over the years, he’s designed all sorts of interesting "stuff," from silicon chips to circuit boards and from brainwave amplifiers to Steampunk Prognostication Engines (don’t ask). He has also been at the forefront of electronic design automation (EDA) for more than 45 years.
Max moved to America in 1990. He’s written several books (search for “Clive Maxfield” on Amazon) and his numerous technical articles have appeared in a wide variety of electronics and computing magazines.
In addition to being a freelance technical consultant and writer, Max is currently CTO of the LogiSwitch switch debounce company (www.logiswitch.com) and Editor in Chief of Designing Electronics North America (DENA) (www.designing-electronics.com).
Switches bounce -- that's what they do. To ensure our processors don't "see" multiple events, we have to debounce these signals, which we can do in hardware or software. Unfortunately, this is something of an arcane area because there are as many different approaches as there are engineers (some of them even work). In this MicroTalk, we will plunge into this esoteric topic with gusto and abandon, so please ensure you are wearing appropriate attire.
What is the fundamental reason the speaker says you must debounce mechanical switches before feeding their signals to a microcontroller?
AMechanical switches generate multiple rapid make/break events (bounces) on both closing and opening, which can make the MCU see multiple false events.
BSwitches slowly change voltage because they are analog devices, so you must convert them to digital first to avoid misreads.
CDebouncing is only necessary for normally-closed switches; normally-open switches do not bounce.
DDebouncing prevents the pull-up resistor from overheating due to continuous current flow through the switch.
EDebouncing is only needed if the switch is used to generate time-critical signals like PWM.
When using an RC network as part of a switch-driven reset or debounce circuit, what specific hardware warning did the speaker give?
ADo not place the switch directly across the capacitor, because depending on capacitor size you can get very large currents.
BAlways use the largest possible capacitor to guarantee the longest debounce time and prevent any bounces.
CA single resistor in series with the capacitor is sufficient; adding more resistors only makes the circuit worse.
DYou should omit the Schmitt-trigger buffer because the RC alone always produces a perfectly sharp transition.
ETie the capacitor directly to VCC to ensure the reset line is active low at power-up.
Why did the speaker favor the shift-register (bit-history) method for software debounce over a simple counter with a blocking delay?
ABecause the shift-register method uses a fixed per-tick operation (shift, insert, mask, compare), is non-blocking and simplifies logic for detecting a stable state over multiple samples.
BBecause the shift-register method requires less memory than a single counter, making it ideal for tiny 8-bit micros.
CBecause the shift-register approach eliminates the need to sample the switch at regular intervals.
DBecause the shift-register method only works with blocking delay() calls, which guarantees timing accuracy.
EBecause the shift-register approach guarantees zero latency between the physical switch action and the detected event.