Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Debounce a Contact (2014)

ganssle.com

Post reply on HN
Print view View original

51–60 of 82 posts

Re: How to Debounce a Contact (2014)

#51

Post by Certified »

the__alchemist wrote: post #40
Certified wrote: post #30

I'm a big fan of debouncing in hardware with the MAX3218 chip. It will debounce by waiting 40ms for the signal to "settle" before passing it on. This saves your microprocessor interrupts for other things. It also will work with 12 or 24 volt inputs and happily output 3.3 or 5v logic to the microprocessor. It is pricey though at $6-10 each.

My thought is: This introduces latency that is not required (40ms could be a lot IMO depending on the use.) It's not required because you don't need latency on the first high/low signal; you only need to block subsequent ones in the bounce period; no reason to add latency to the initial push. Also, (Again, depends on the use), there is a good chance you're handling button pushes using interrupts regardless of debounc…

I guess I should rephrase. It saves all the interrupts except the one triggered at 40ms delay. For every button press without hardware debouncing, you can have 10s - 100s of 1to0 and 0to1 transitions on the microcontroller pin. This is easily verified on a oscope, even with "good" $50+ honeywell limit switches. Every single one of those transitions triggers an interrupt and robs cpu cycles from other things the microprocessor is doing. The code in the interrupt gets more complex because now it has to do flag checks and use timers (bit bashing) every time they are triggered instead of just doing the action the button is supposed to trigger. None of this is to say one way is the "right" or "wrong" way to do it, but putting the hardware debouncing complexity into hardware specifically designed to handling it, and focusing on the problem I am actually trying to solve in firmware is my personal preferred way of doing it.

Re: How to Debounce a Contact (2014)

#52

Post by michaelt »

theamk wrote: post #45
michaelt wrote: post #8

Earlier quoted context omitted.

> 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…

You've read the article, right? None of the code author gives need "64-bit count of milliseconds" nor floating-point logic. 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.

Do you mean this code, from the article?

  uint8_t DebouncePin(uint8_t pin) {
      static uint8_t debounced_state = LOW;
      static uint8_t candidate_state = 0;
      candidate_state = candidate_state
That doesn't work if you've got more than one pin, as every pin's value is being appended to the same candidate_state variable.

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 :)

Re: How to Debounce a Contact (2014)

#53

Post by aidenn0 »

Certified wrote: post #30

I'm a big fan of debouncing in hardware with the MAX3218 chip. It will debounce by waiting 40ms for the signal to "settle" before passing it on. This saves your microprocessor interrupts for other things. It also will work with 12 or 24 volt inputs and happily output 3.3 or 5v logic to the microprocessor. It is pricey though at $6-10 each.

That chip is more expensive than having a dedicated microcontroller that polls all of its GPIOs, performing software debouncing continually, and sends an interrupt on any change.

Re: How to Debounce a Contact (2014)

#54

Post by theamk »

michaelt wrote: post #52
theamk wrote: post #45

Earlier quoted context omitted.

You've read the article, right? None of the code author gives need "64-bit count of milliseconds" nor floating-point logic. 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.

Do you mean this code, from the article? uint8_t DebouncePin(uint8_t pin) { static uint8_t debounced_state = LOW; static uint8_t candidate_state = 0; candidate_state = candidate_state That doesn't work if you've got more than one pin, as every pin's value is being appended to the same candidate_state variable. The fact the author's correspondent, the author, and you all overlooked that bug might help you understand w…

I don't think anyone is overlooking anything, because it should be pretty clear this code is a template, meant to be modified to fit the project style.

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.

Re: How to Debounce a Contact (2014)

#55

Post by [deleted] »

somat wrote: post #16
khafra wrote: post #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 subco…

nobody cares enough to actually do it. but what would it take to have near instantaneous channel changes again?, prestarting a second stream in the background? And realistically the linear array of channels is also dead so it really does not matter. so I guess the modern equivalent is having a snappy UI. A horrible idea, as if our current tv features were not already bad enough. the modern equivalent to quick channel…

[deleted]

Re: How to Debounce a Contact (2014)

#56

Post by Certified »

Certified wrote: post #30

I'm a big fan of debouncing in hardware with the MAX3218 chip. It will debounce by waiting 40ms for the signal to "settle" before passing it on. This saves your microprocessor interrupts for other things. It also will work with 12 or 24 volt inputs and happily output 3.3 or 5v logic to the microprocessor. It is pricey though at $6-10 each.

Edit: I meant to call out the MAX6818, not MAX 3218

Re: How to Debounce a Contact (2014)

#57

Post by Certified »

aidenn0 wrote: post #53
Certified wrote: post #30

I'm a big fan of debouncing in hardware with the MAX3218 chip. It will debounce by waiting 40ms for the signal to "settle" before passing it on. This saves your microprocessor interrupts for other things. It also will work with 12 or 24 volt inputs and happily output 3.3 or 5v logic to the microprocessor. It is pricey though at $6-10 each.

That chip is more expensive than having a dedicated microcontroller that polls all of its GPIOs, performing software debouncing continually, and sends an interrupt on any change.

It's price is it's biggest drawback, but it is also replacing any electronics used to run the switches at 12 or 24v which gets you above the noise floor if you are operating next to something noisy like a VFD. from the 6818 data sheet: "Robust switch inputs handle ±25V levels and are ±15kV ESD-protected" [1]

[1] https://www.analog.com/media/en/technical-documentation/data...

Re: How to Debounce a Contact (2014)

#58

Post by Certified »

theamk wrote: post #50
Certified wrote: post #30

I'm a big fan of debouncing in hardware with the MAX3218 chip. It will debounce by waiting 40ms for the signal to "settle" before passing it on. This saves your microprocessor interrupts for other things. It also will work with 12 or 24 volt inputs and happily output 3.3 or 5v logic to the microprocessor. It is pricey though at $6-10 each.

that seems like a real overkill - it's a full-blown RS232 receiver _and_ transmitter, including two DC-DC converters (with inductor and capacitor) that you don't even use... Also, "R_IN absolute max voltage" is +/- 25V, so I really would not use this in 24V system. 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 di…

Thanks for pointing that out. I realized I called out the wrong chip. I was actually trying to call out the Max6818.

Re: How to Debounce a Contact (2014)

#59

Post by myself248 »

1970-01-01 wrote: post #46
HPsquared wrote: post #37

Earlier quoted context omitted.

It used to be fun and rewarding to flip through channels on analogue equipment. No buffering, no delay, just press, flash to the next channel.

What's truly been lost is the speed 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 ha…

Seriously. Analog stuff was wild. You could have telephones in adjacent rooms, call one from the other, and your voice would come out the telephone (having traveled electrically all the way across town and back) before the sound came down the hall. Analog cellphones were like that too -- ludicrously low latency.

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.

Re: How to Debounce a Contact (2014)

#60

Post by myself248 »

khafra wrote: post #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 subco…

Lightswitches are like this for me now. Activating the switch still produces an audible and subtly-tactile click, but then some awful software has to think about it for a moment and close a relay, and then a whole power supply in an LED module somewhere has to start up.

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.

Post reply on HN