How to Debounce a Contact (2014)
ganssle.com
How to Debounce a Contact (2014)
1–10 of 82 posts
Re: How to Debounce a Contact (2014)
#2I saw this site in one of the comments on https://hackaday.com/2025/01/04/button-debouncing-with-smart...
Re: How to Debounce a Contact (2014)
#3My test whenever I get handed someone else's code with a debounce routine is to hammer the buttons with rapid presses, gradually slowing down. That shows if the filter is too aggressive and misses legitimate presses. I also see strange behavior when they're implemented wrong like extra presses that didn't happen or getting stuck thinking the button is still held when it isn't.
Re: How to Debounce a Contact (2014)
#4This is one of the best treatises on debounce, I've read it a number of times and probably will again.
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.
Re: How to Debounce a Contact (2014)
#5Analysis is nice, although the graph style is very much 2005.
The conclusion is that as long as you don't get a crappy switch, 10mS debounce interval should be sufficient.
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.)
Re: How to Debounce a Contact (2014)
#6> One vendor told me reliability simply isn't important as users will subconsciously hit the button again and again till the channel changes.
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.
Re: How to Debounce a Contact (2014)
#7My test whenever I get handed someone else's code with a debounce routine is to hammer the buttons with rapid presses, gradually slowing down. That shows if the filter is too aggressive and misses legitimate presses. I also see strange behavior when they're implemented wrong like extra presses that didn't happen or getting stuck thinking the button is still held when it isn't.
What kind of line of work gives you the ability to discuss debounce routines as an everyday enough occurrence to speak with authority on the matter, if you don’t mind me asking?
Re: How to Debounce a Contact (2014)
#8Analysis is nice, although the graph style is very much 2005. The conclusion is that as long as you don't get a crappy switch, 10mS debounce interval should be sufficient. 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…
> Also, I don't get why the text makes firmware debouncer sound hard?
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.
Re: How to Debounce a Contact (2014)
#9Analysis is nice, although the graph style is very much 2005. The conclusion is that as long as you don't get a crappy switch, 10mS debounce interval should be sufficient. 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…
> Also, I don't get why the text makes firmware debouncer sound hard? 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 in…
>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.
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.
Re: How to Debounce a Contact (2014)
#10I just bought a horrible Lenovo keyboard with terrible debouncing. For some reason, it seems to only affect the vowels... is this sabotage?