How to Debounce a Contact (2014)
ganssle.com
ganssle.com
:-)
I had a similar experience with a elevator motor and a terminal. The electronics worked absolutely fine, but when someone operated the elevator it occasionally produced phantom keypresses on the capacitive keypad.
This was perhaps understandable, but what really confused the users was that these phantom keypresses sometimes pressed the not fitted debug buttons (which weren't on the production keypad) which stuck the device into debug mode!
We learnt not to include the debug code in the production firmware and beefed up the transient suppression hardware and the debouncing firmware to fix.
The EE and I were standing around the machine and he happened to be in front of the UI when it reset and I mentioned that I heard a soft click just before he said that it reset, but we had no hardware in the region where I thought the noise came from.
Finally, we put two and two together and realized that the system included a propane heater with an automatic controller and the noise I heard was probably the propane igniter. The high voltage from the igniter was wirelessly coupling into one of the I/O lines going to the controller board. The reason that the problem had suddenly started happening after months of trouble-free development was that the customer had rerouted some of the wiring when they were in the machine fixing something else and moved it closer to the heater.
In 30 years of doing this, I can count on one hand the number of times I've had to deal with noise that was coupling in through the air!
I can’t tell any specific stories but poorly shielded USB ports were the bane of our existence in the 2000s. Every motherboard would come with them and the second a random floor worker would plug something in it’d take down a section of the fab or all of the microscopes even if it were on the other side of the building. For some god forsaken reason all the SBC manufacturers used by tons of the bespoke equipment were also adding USB ports everywhere. We ended up glueing all of them shut over the course of the several months it took to discover each machine as floor workers circumvented the ban on USB devices (they had deadlines to meet so short of gluing them shut we couldn’t really enforce the ban).
- an am radio station nearby coupling into a pbx
- when some genius thought it would be a good idea to run Ethernet down the elevator shaft, right next to the lines feeding its truck sized motor.
many years ago I wired up my own design for an 8080 system, but i was a self taught beginner and not very good at stuff like a capacitive RC debounce circuit so I couldn't get my single-step-the-CPU button to work.
I was reading the spec sheet for the processor and I realized I could kluge it with signals. There was something like a "memory wait" pin, and another one called something like "halt", but one fired on the leading edge of the clock, and the other on the trailing edge, so I was able to use a SPDT push button and a flip flop to single step halt/memory wait on the first bounce, and then restart only on the first bounce when the button was released.
It's impossible to guess how users will use a system until they can be observed in the wild.
Orthogonally to the point of this excellent article, I found it striking how this was probably true, once--and then TVs got smart enough that it took seconds to change channels, instead of milliseconds. And then it was no longer possible for input failures to be corrected subconsciously.
It's slower enough, compared to incandescent, to juuuuust make me flinch back and almost hit the switch again, but nope, it worked the first time after all.
I don't have a term for the annoyance of that flinch, but I should.
20 years ago was when I could flip through all (40ish) analogue CATV channels * in under 20 seconds * and could tell you what shows were going on with each channel.
Yes, it only took around 500ms to filter and decide if each station broadcast was on commercial, news, sports, nature, or something else worth watching.
To this day, with all the CDNs and YouTube evolutions, we still have not come close to receiving video variety anywhere near that speed.
Being able to interrupt each other without the delay-dance of "no, you go ahead" *pause* was huge. Digital cellular networks just enshittified that one day in about 2002 and apparently most folks just didn't care? I curse it every time I have to talk on the godforsaken phone.
People cared, your comment made me remember comments my parents made about this problem. However, digital cell signals fixed a ton of congestion issues that analog was having and lowered the price so much people could actually afford to have cell phones.
It means that for instance, storing an entire frame of video is nothing today, but in the analog times, it was hard, it means you simply didn't have enough storage for high latency. Now, you can comfortably save several frames of video, which is nice since more data means better compression, better error correction, etc... at the cost of more latency. Had memory be expensive and speed plentiful, a more direct pathway would have been cheaper, and latency naturally lower.
No. It is the software. Just look at Windows: Windows 10 and 11 has a third of functionality of 7 being 10 times bigger. What 10 years ago needed a mouse click, it needs 3 today. Software must communicate with the mothership so that mothership can see which functions are not used and remove them, making the program useless. And security: it just got more layers. Which, most of the time are useless and easy to bypass.
A horrible idea, as if our current tv features were not already bad enough. the modern equivalent to quick channel changes would be a learning model that guesses what you you want to see next, has that stream prestarted then have the "next channel" button tied to activate that stream. The actual reason this is a bad idea, I mean above and beyond the idea that we want learning models in our tv's. Is that the manufactures would very quickly figure out that instead of the agent working for their customers they could sell preferential weights to the highest bidder.
closing thought... Oh shit I just reinvent youtube shorts(or perhaps tik tok, but I have managed to avoid that platform so far)... an interface I despise with a passion.
Of course this will be non-trivial on server side - constantly decode each channel's stream, take a snapshot every few seconds, re-encode to JPEG, serve to clients... And since channels are dead, no one is going to do this.
Furthermore, once a user starts flipping channels, since most flipping is just prev/next, you could start proactively sending them the frames for the adjacent channels of where they are, and reduce the show-delay to nearly nothing at all. When they calm down and haven't flipped for a while, stop this to save bandwidth.
The main issue is that the switching "app" is not yet loaded. /s
"With all those DLLs and network access, Dave, you're going to find this rather difficult" /s
What's crucial, though, is that mistakes or overshoots can be (a) detected (for example, if three presses were detected, show three arrows) and (b) corrected without having to wait for the channel change to complete.
One of the best things I've done to help with really bad debounce is spend time testing a number of buttons to find the designs that have, at the hardware/contact level, much less bounce. Some buttons wind up with tens of ms of bounce, and it's hard to correct for it and meet expectations all in software.
> Never run the cap directly to the input on a microprocessor, or to pretty much any I/O device. Few of these have any input hysteresis.
that's not true today, most small MCU made in 2005 or later (such as AVR and STM8 series) have input hysteresis, so feel free to connect cap directly to it.
And when he says:
> don't tie undebounced switches, even if Schmitt Triggered, to interrupt inputs on the CPU
that's also not correct for most modern CPUs, they no longer have a dedicated interrupt line, and interrupts share hardware (including synchronizer) with GPIO. So feel free to tie undebounced switch to interrupt lines.
And if you do end up choosing SPDT switch, then there are much simpler designs which have switch toggle between Vcc and GND, like Don Lancaster's debouncer [0]. That design is especially useful if you have many switches, as you can wire all VCCs and GNDs in parallel, and use 8-channel buffers to debounce multiple ones.
The SR latch schematics only makes sense if you are working with TTL logic (popular in 1970/1980) which did not nave a symmetric drive output pattern, and there is absolutely no reason to use it in 2000's.
[0] https://modwiggler.com/forum/viewtopic.php?p=275228&sid=52c0...
- Button triggers interrupt
- Interrupt starts a timer
- Next time interrupt fires, take no action if the timer is running. (Or use a state variable of some sort)
lol, or you could do what my TV does- say "to hell with user experience" and use an interrupt timer anyway.
If I hold down my volume-up button (The physical one on the TV!), I get a quick and fluid increase. But if I hammer the button 4 times per second, the volume still only goes up 1 ticke per second.
I would not pay much attention to the rest of the text.
The hardware debouncer advice is pretty stale - most of the modern small MCUs have no problem with intermediate levels, nor with high frequency glitches. Schmidt triggers are pretty common, so feel free to ignore the advice and connect cap to MCU input directly. Or skip the cap, and do everything in firmware, MCU will be fine, even with interrupts.
(Also, I don't get why the text makes firmware debouncer sound hard? There are some very simple and reliable examples, include the last one in the text which only takes a few lines of code.)
The article links to Microchip's PIC12F629 which is presumably the type of chip the author was working with at the time.
This would usually have been programmed in assembly language. Your program could be no longer than 1024 instructions, and you only had 64 bytes of RAM available.
No floating point support, and if you want to multiply or divide integers? You'll need to do it in software, using up some of your precious 1024 instructions. You could get a C compiler for the chips, but it cost a week's wages - and between the chip's incredibly clunky support for indirect addressing and the fact there were only 64 bytes of RAM, languages that needed a stack came at a high price in size and performance too.
And while we PC programmers can just get the time as a 64-bit count of milliseconds and not have to worry about rollovers or whether the time changed while you were in the process of reading it - when you only have an 8-bit microcontroller that was an unimaginable luxury. You'd get an 8-bit clock and a 16-bit clock, and if you needed more than that you'd use interrupt handlers.
It's still a neat chip, though - and the entire instruction set could be defined on a single sheet of paper, so although it was assembly language programming it was a lot easier than x86 assembly programming.
EDIT: in fact with a 16 bit timer, a clock rollover happens exactly every 13 milliseconds, which is a pretty good denounce interval.
But a person working on such resource-constrained chips might have felt software debouncing was somewhat difficult, because the resource constraints made everything difficult.
Note that a lot of the content that Jack posted on his site or in the newsletter was written years, if not decades ago in one of his books or when he was writing for "Embedded Systems Programming" magazine. He was (completely retired last year) pretty good about only reposting content that was still relevant, but every so often you'd see something that was now completely unnecessary.
The last example (that I've mentioned in my comment) needs a single byte of RAM for state, and updating it involves one logic shift, one "or", and two/three compare + jumps. Easy to do even in assembly with 64 bytes of RAM.
uint8_t DebouncePin(uint8_t pin) {
static uint8_t debounced_state = LOW;
static uint8_t candidate_state = 0;
candidate_state = candidate_state << 1 | digitalRead(pin);
if (candidate_state == 0xff)
debounced_state = HIGH;
else if (candidate_state == 0x00)
debounced_state = LOW;
return debounced_state;
}
The fact the author's correspondent, the author, and you all overlooked that bug might help you understand why some people find it takes a few attempts to get firmware debouncing right :)
In particular, that's not in assembly (we were talking about assembly), and uses arduino-style digitalRead and HIGH/LOW constants, which simply do not not exist on PIC12F629 or any other MCUs with 64 bytes of RAM. Translating this to non-Arduino would likely be done by replacing digitalRead with appropriate macro and removing "pin" argument.
But if you want to talk more generally about atrocious state of firmware development, where people are just copy-pasting code from internet without understanding what it does, then yeah... there seems to be something in firmware development which encourages sloppy thinking and wild experimenting instead of reading the manual. I've seen people struggle to initialize _GPIO_ without the helpers, despite this being like 2-3 register writes with very simple explanations in the datasheet.
Very much not true as almost nobody ever used floating point in commercial embedded applications. What you use is fractional fixed point integer math. Used to be working in Automotive EV motor control in the past and even though the MCUs/DSPs we used had floating point HW for a long time now, we still never ued it for safety and code portability reasons. All math was fractional integer. Maybe today's ECUs started using floating point but that was definitely not the case in the past, and every embedded dev wort his salt should be comfortable doing DSP math in without floating point.
I agree that fixed point is great and that floating point has portability problems and adds subtle correctness concerns.
A lot of early (60s and 70s) embedded control was done with programmable calculators, incidentally, because the 8048 didn't ship until 01977: https://www.eejournal.com/article/a-history-of-early-microco... and so for a while using something like an HP9825 seemed like a reasonable idea for some applications. Which of course meant all your math was decimal floating point.
Weren't those just PC computers and less microcontrollers?
The price of silicon has dropped so precipitously in the last 20 years that it's hard to imagine the lengths we had to go to in order to do very simple things.
NO, that's not what I meant. I said you didn't need it in the first place anyway since it wasn't widely used in commercial applications.
If there are problems like double channel jumps or missed commands, it’s more about how the receiver interprets the repeated signals rather than a classic switch debounce issue. There’s definitely a similarity in handling timing and filtering inputs, but it seems like the core issue with remotes is different, as they must already handle repeated commands by design.
I got lots of different suggestions, none of which worked, until I found one that did: 1) switch is pulled high or low as needed 2) switch has capacitor to ground 3) switch signal goes through a schmitt trigger
I designed this into its own PCB which I had manufactured and soldered the SMD and through-hole and ICs to that, and treat it as its own standalone signal source. Once I did that, literally every obscure problem I was having disappeared and the downstream counter worked perfectly.
When you look at the various waveforms (I added a bunch of test points to the PCB to make this easy) the results of my PCB produces perfect square waves. I found it interesting how many suggested hardware solutions I had to try (simple RC filter did not work) and how many "experts" I had to ignore before I found a simple solution.
I build medical devices.
https://www.ganssle.com/reports/ultra-low-power-design.html
One of the best practical EE essays I’ve ever read, and a masterwork on designing battery powered devices.
[1] https://www.analog.com/media/en/technical-documentation/data...
Also, (Again, depends on the use), there is a good chance you're handling button pushes using interrupts regardless of debouncing.
If you want slow and reliable input for industrial automation, it seems much safer to make one yourself - an input resistor, hefty diode/zener, voltage divider, maybe a schmitt trigger/debouncer made from opamp if you want to get real fancy.
but yeah, very expensive for what it does. If my MCU was really short on interrupts, I'd go with I2C bus expander with 5v-tolerant inputs and INT output - sure, it needs explicit protection for 24V operation, but it also only needs 3 pins and 1 interrupt.
I'm still running their code right now on my watch. It uses timers to allow the switch to settle before triggering input events. Dramatically improved its usability. Latency noticeably increased but without it interfaces which required holding down buttons simply didn't work reliably.
What does it mean that a flip-flop gets confused? What kind of undesired operation could that cause?
Because, quite honestly, if connecting directly means occasional transient failures, then having less hardware is a tempting tradeoff on small PCBs.