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

11–20 of 82 posts

Re: How to Debounce a Contact (2014)

#11

Post by hamandcheese »

Cumpiler69 wrote: post #9
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…

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

Are you saying that it isn't true that there was not floating point support? That there actually was, but nobody used it? I don't see how that changes the thrust of the parent comment in any significant way, but I feel like I may be misunderstanding.

Re: How to Debounce a Contact (2014)

#12

Post by Cumpiler69 »

hamandcheese wrote: post #11
Cumpiler69 wrote: post #9

Earlier quoted context omitted.

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

Are you saying that it isn't true that there was not floating point support? That there actually was, but nobody used it? I don't see how that changes the thrust of the parent comment in any significant way, but I feel like I may be misunderstanding.

>Are you saying that it isn't true that there was not floating point support?

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.

Re: How to Debounce a Contact (2014)

#13

Post by bambax »

> Years ago a pal and I installed a system for the Secret Service that had thousands of very expensive switches on panels in a control room. We battled with a unique set of bounce challenges because the uniformed officers were too lazy to stand up and press a button. They tossed rulers at the panels from across the room. Different impacts created quite an array of bouncing.

It's impossible to guess how users will use a system until they can be observed in the wild.

Re: How to Debounce a Contact (2014)

#14

Post by XorNot »

michaelt wrote: post #8
theamk wrote: post #5

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

That chip has a 200ns instruction cycle though. Whatever program you're running is so small that you can just do things linearly: i.e. once the input goes high you just keep checking if it's high in your main loop by counting clock rollovers. You don't need interrupts, because you know exactly the minimum and maximum number of instructions you'll run before you get back to your conditional.

EDIT: in fact with a 16 bit timer, a clock rollover happens exactly every 13 milliseconds, which is a pretty good denounce interval.

Re: How to Debounce a Contact (2014)

#15

Post by matheusmoreira »

Wish I had known about this article last year when developers added debouncing to the Sensor Watch project. I had to learn a lot of this from scratch in order to review and merge in their changes.

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.

Re: How to Debounce a Contact (2014)

#16

Post by somat »

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

Re: How to Debounce a Contact (2014)

#17

Post by michaelt »

XorNot wrote: post #14
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…

That chip has a 200ns instruction cycle though. Whatever program you're running is so small that you can just do things linearly: i.e. once the input goes high you just keep checking if it's high in your main loop by counting clock rollovers. You don't need interrupts, because you know exactly the minimum and maximum number of instructions you'll run before you get back to your conditional. EDIT: in fact with a 16 bi…

Sure! I'm not saying debouncing in software was impossible.

But a person working on such resource-constrained chips might have felt software debouncing was somewhat difficult, because the resource constraints made everything difficult.

Re: How to Debounce a Contact (2014)

#18

Post by jakewins »

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…

There was some article from early instagram times about this the other week - that an innovation there was that they started the upload as soon as the picture was taken, so after the user filled out the caption part and hit “submit”, the “upload” was instantaneous

Re: How to Debounce a Contact (2014)

#20

Post by ghusbands »

This is an interesting take on debouncing, but I found the choice of TV remotes as an example a bit confusing. From my understanding, the issues with remote controls aren’t typically caused by bouncing in the mechanical sense but rather by the design of the IR communication. Most remotes transmit commands multiple times per second (e.g., 9–30 times) intentionally, and the receiver handles these signals based on timing choices.

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.

Post reply on HN