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?
How to Debounce a Contact (2014)
41–50 of 82 posts
Re: How to Debounce a Contact (2014)
#42> 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 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)
#43I'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.
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> 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…
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)
#45Analysis 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…
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> 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.
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)
#47Re: How to Debounce a Contact (2014)
#48https://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.
Re: How to Debounce a Contact (2014)
#49This 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.
> 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)
#50I'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.
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.