On 26.03.19 10:38, Chris Albertson wrote: > A very basic question, unlike the hards ones being discussed here but, > important I think. > > How are people handling switch debouncing on home and limit switches? > > Always in the past, I have treated the microswitch is a SPST device that is > either open or closed. > The common terminal is pulled up to Vcc voltage and when the switch closes > it connects to ground. > > But all my switches have three terminals.
OK, it's about 40 years ago now, but when I did hardware debouncing, it was with a pair of cross-coupled 2-input NAND gates making a flip-flop, a pull-up on each switch-connected input, and switch common to ground. NO and NC went to the two FF inputs. That gave two debouncers per 7400 (74HC00 these days). That _will_ give latency in the nanosecond range, and very sharp risetimes. N.B. If driving more than a few inches of wire, buffer the output with a spare gate, otherwise line reflections can flip the flop, as feedback is from the output. A tri-state buffer was best practice on a line in the metre range. It could also be done with two inverters, cross-coupled with resistors, which then serve as the pull-ups. That gives 3 debouncers per package, with no extra discrete components. (Or two with an output buffer each.) Since then it's been software debouncing for me, including a specified algorithm for the first generation of 2.048 Mb/s PCM trunk 30 channel pair gain systems introducing digital telephony to Australia. Since it was debouncing 10 PPS 60:40 rotary dial pulses, mark:space distortion was an issue - though far less critical than a homing stop. Heck, that was back in '81 - '82. Those trailblazing systems will be decommissioned as superseded long ago now. The first used an 8085, the single-chip, single voltage, version of the 3-chip 8080, yet handled the signalling protocol with only 62.5 uS per channel on average. > I did some experiments using my > digital oscilloscope. The normal > method causes a long series of "bounces" that continue for some number of > milliseconds the new method > makes a near-perfect single pulse square wave. I see oscillation for only > about 10 nanoseconds when the switch > closes and no bounce at all when it opens. > > Common terminal goes to the computer and uses a 10K pull-up. NC terminal > goes to Vcc and NO to ground. I place a 0.1 uF cap from common to ground. > I notice the cap can "ring" and go below ground. So I place a small > diode from common to the ground to protect the uP from negative volts. > All the passive components are soldered directly to the switch terminals. Yes, the fall time is short, but with a high switch current for nS, The effect on contact life is uncertain, though it could melt the micro-roughness peak which makes first contact. That then probably smoothes out, and later contacts are over a surface area which happily absorbs the nanojoules of energy. A switch replacement after a few years would not be a great burden, if needed, but a 100 ohm discharge resistor would allay any concerns, I figure. > Yes, I know a switch can be de-bounced in software but this introduces > latency as the software has to keep checking the state of the switch. > Reduced latency very much increases the accuracy of the microswitch. > > If you have a digital scope you can try rig up some experiments. Again > the only "trick" is to use all three terminals on the switch. Software can also respond on the first bounce, but your capacitor acts as a noise filter on the input - without introducing delays, when shorted by the switch. Can't do that in software. Time is the price of a virtual solution. > Yes, I foresaw all kinds of problems but as it turns out in practice I get > nanosecond level latencies. > > Perhaps everyone already is doing this and I was the last to think of it. > The switch still actually bounce but in this case, bouncing does not cause > a change of state. No, the slow rise time, due to the pull-up timeconstant sees to that - without introducing any latency. Yes, it is too easy to forget the hardware path these days. Erik _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
