Live data from Hacker News

How to Debounce a Contact (2014)

ganssle.com

41–50 of 82 posts

Re: How to Debounce a Contact (2014)

#41
post #32

Earlier quoted context omitted.

Plenty of embedded microcontrollers in the 70s and later not only used floating point but used BASIC interpreters where math was floating point by default. Not all commercial embedded applications are avionics and ECUs. A lot of them are more like TV remote controls, fish finders, vending machines, inkjet printers, etc. I agree that fixed point is great and that floating point has portability problems and adds subtle…

>Plenty of embedded microcontrollers in the 70s Weren't those just PC computers and less microcontrollers?

No, though chips like the 80186 did blur the line. But what I mean is that different companies sold things like 8051s with BASIC in ROM. Parallax had a very popular product in this category based on a PIC, you've probably heard of it: the BASIC Stamp.

Re: How to Debounce a Contact (2014)

#42
post #21

> But some environments are notoriously noisy. Many years ago I put a system using several Z80s and a PDP-11 in a steel mill. A motor the size of a house drawing thousands of amps drove the production line. It reversed direction every few seconds. The noise generated by that changeover coupled everywhere, and destroyed everything electronic unless carefully protected. We optocoupled all cabling simply to keep the smo…

My favorite noise story is from just a couple years ago. Our controller would run fine for hours or days and then reset for no apparent reason. Looking at the debug output, I could tell that it wasn't a watchdog or other internal reset (e.g., system panic) and there had been no user input. The debug log basically said that someone pushed the reset button, which clearly wasn't happening. The EE and I were standing aro…

I’ve worked with electron microscopes and in silicon fabs and it’s super fun being on the teams hunting for sources of noise during construction and bringup. In fabs there are multiple teams because it’s so specialized, the HVAC team being the most interesting one because they’ve got tons of mechanical and electronic sources all over the buildings. They were also the long tail for problems with yield (which was expected and budgeted for). I think the EM startup I worked for failed in part due to not taking the issue seriously enough.

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

Re: How to Debounce a Contact (2014)

#43

I've been using the perhaps-too-simple: - 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) Of note, this won't work well if the bounce interval is close to the expected actuation speed, or if the timeout interval isn't near this region.

> this won't work well if the bounce interval is close to the expected actuation speed

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.

Re: How to Debounce a Contact (2014)

#44
post #16
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…

a workaround for IP-based TVs may be some sort of splash/loading screen that shows recent-ish screenshot of the channel very quickly. It'd still take a long time for picture to start moving, but at least user will see something and could switch away quickly if they don't care about content at all.

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.

Re: How to Debounce a Contact (2014)

#45
post #8
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…

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.

Re: How to Debounce a Contact (2014)

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

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 have not come close to receiving video variety anywhere near that speed.

Re: How to Debounce a Contact (2014)

#49

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

Just don't implement SR debouncer, OK? And don't use MC140* series chips, those don't work with 3.3V used by modern micros. And when he says:

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

Re: How to Debounce a Contact (2014)

#50

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 divider, maybe a schmitt trigger/debouncer made from opamp if you want to get real fancy.

Post reply on HN