switch debouncing

He also wrote a somewhat longer piece a little later on, that year:

Jon

But firmware is free!

If you sample the switch state periodically at a rate slower than the longest possible bounce time, then you don't need to do any software debouncing. Something like 5-10 Hz sample rate plays right into typematic logic if you want to do that, too.

John

It should work as long as you don't need to know the exact instant that the switch operated.

-- Dan Hollands

If it's going into a microcontroller, firmware is almost always the best way.

Best regards, Spehro Pefhany

Timer-interrupt driven periodic (in the 100-500Hz range) polling uses negligible bandwidth of a modern processor for any reasonable number of keys. Even if its a frequent occurence. And it can filter out electrical noise and momentary contact breaks due to shock or vibaration as well, if you choose to write it to do so.

There is reason to add some external hardware (especially to deal with ESD issues and possibly with the miserably small and variable current that on-board pullups typically deliver) but not for the deboucing. Even a crummy on-board RC clock will yield debouncing times accurate within a few percent at zero additional cost, and les need to test the board for missing parts.

Best regards, Spehro Pefhany

What is it with you people looking for a "standard way" all the time?

Pure "bit head" guess work. The worst case occurs when the switch opens on bounce immediately after pulling the Schmitt input across its low threshold and the circuit starts to recharge C back towards Vcc. You obviously don't want the voltage to cross the positive threshold again. Using VT+ as positive threshold, VT- as negative threshold, and VH as hysteresis, a worst case calculation for the 74HC14 would look something like this when you settle on a maximum bounce time an order of magnitude larger than switch specification. This usually means less than one chance in a billion of ever seeing a glitch aka switch has failed. A 5ms switch calculation would look like so: View in a fixed-width font such as Courier.

. . . . VCC . | . | . [R1] . | . | . | |\\ . +-[R2]-+----| o------->

. | | |/ . o | . -| === 74HC14 . o |C . | | . +------+ . | . --- . /// . . . . Vcc-VT- . Worst Case: tau=(R1+R2) x C Tchrg= tau x LN( ------ ) . Vcc-VT+ . . Vh,min 0.4 . Tchrg= tau x LN ( 1 + -----------) = tau x LN(1 + -----) . Vcc-VT+,min 5-1.7 . . . . Tchrg,min= tau x 0.1 must exceed Tbounce_high,max . . . R1=82K and R2=18K C=1u => tau=100ms => Tchrg,min= 10ms . . . This is insufficient. Allow for Tbounce_high,max=50ms then . . . tau x 0.1 = 50ms or tau=500ms => C=4.7u for R1=82K and R2=82K . . . 1u . max lkg charge up = dV/dt = --- = 0.2uV/us x 50ms=10mV worst case . 4.7u . . -5 . maximum hold down time= 18K x 4.7U x LN( ---- ) = 150ms . -0.9 . . .

Well, if you can arrange things with external hardware so that the switch input is always valid, that is just that much less the firmware has to do- especially if the switch input is a very infrequent occurrence.

ESD protection is a good point... you may also want to put a 1uF cap directly across the switch to keep the contacts clean, making a small spark...I have a MD player where the switches are all dry contacts i.e. very low current, and they are a problem...

Mark

Mark

Maxim have a range of switch debouncers, a bit expensive, but it could save software. Jack Ganssle did a review of real switches, and measured their bounce times. Might be on his site

martin

With those resistor values the 'debounce time' wil be very different for opening and closing the switch.

Graham

The link in my post is to an article by Ganssle.

--Mac

No. It will be going to a logic gate.

I am not going to put a 1uF cap directly across the switch. That seems like an exceptionally bad idea to me.

ESD is NOT my thing, but the ESD spike in this case will have to charge (or discharge) a 1 uF cap through an 18k resistor in order to endanger the gate. The path to VCC is even more difficult since there is an 82k resistor there. I am assuming that the 18k will give the protection diodes on the gate a fighting chance, I guess.

Also, the switch is designed so that the discharge will almost certainly be to ground, not to the switch contacts.

--Mac

I just checked. The switch I have in mind

On the other hand, I have nothing to lose by going to 50 ms. It will still seem instantaneous to human users. I will think about what you have said.

--Mac

This button will be pushed by human fingers. So no worries about that.

--Mac

Thanks. The two pieces are very similar, but the pdf does contain some information not found in the embedded.com article.

--Mac

Makes a very stable oscillator as well. See "CMOS-Osc-NoClip.pdf" on the S.E.D/Schematics page of my website.

...Jim Thompson

I suppose that, if parts are good, then more parts must be better.

John

After reading the article again, you can see that for any given momentary, he observed 2:1 variation in bounce times, and with identical switches he observed 3:1 variation in average bounce times. So that is a factor six right there. Unfortunately, he failed to compare these measurements against published spec values so we don't really know how to translate those numbers. I see that his logic in defining the R1, R2, C network is to first settle on an absolute maximum Tmax well above observed bounce times on a linear scale, he seems to start with 10ms in this case but then he says something about 50% bounce duty and mumbo-jumbos a 20ms for Tmax, then he selects R2 so that a negative going transition from 5V to VT-,max is >=Tmax, and he selects R1 so that the pull-up R1+R2 re-charge time to VT+,min from 0V is >= Tmax. This is somewhat reasonable but allows room for an unreasonable user to glitch the circuit because the initial values may not be 5V and 0V when the switch is abused. The *only* way to eliminate the possibility of glitch in this circuit is to make the transition time across VH >=Tmax going both ways, and this requires longer time constants. I believe you can "enforce" the Ganssle assumptions on the circuit by doing something like this: View in a fixed-width font such as Courier.

. . . . . VCC . | . +-------+ . | | . | - 74HC14 . [R1] ^ . | | G1 . | | |\\ . +-[R2]--+----+---| o---+---->

. | | | |/ | . o | | | . -| - === | . o ^ |C G2 | . | | | /| | . +-------+ +---o |---+ . | \\| . --- . /// .

Now when you have a switch closure that transitions G1 input to VT- ( in a time >=Tmax), G2 reinforces this in a time 2xTpd very much less than any possibility of an (R1+R2)C pull-up through VH, so that G1 input is pulled towards (VT-)-5V, clamped by the diode at -Vf, and the capacitor discharges to 0V top-to-bottom through the diode->G2 output->GND->diode loop and the position of the switch is of no consequence until G1 input reaches 0V, at which point it assume control of the circuit state. You have a similar action upon switch release and G1 input exceeds VT+. The G1 input waveform would look something like this: View in a fixed-width font such as Courier.

. . . +5.7V ----- . | \\ . 5V | | 5V . \\ 20ms VT+ | ------ . \\ / . \\ / . \\ / . \\ VT- / . | / 20ms . | 0V / . | --------- . | | . | / . -0.7V ----- . .