SPDT debounce doesn't

Yep. but Jack G. Ganssle does it much better. Read

You have been gifted with a truly crap debouncing circuit. It seems to be designed to cause maximum 'hash' on any circuits in its neighbourhood and violates most of the accepted rules for safely driving a CMOS input. Even Muntz wouldn't use it . . . .

I'll just hit the highlights:

The capacitor stores 1.25 uJ of energy that is dumped in microseconds or less when the contacts first touch. They *ARE* arcing and *WILL* fail sooner than if you left the cap out. Worse - you are dumping large currents into the power and ground wiring of your circuit.

Assume a total resistance in the loop cap - Switch - ground - other side of cap of 1 ohm, not unreasonable if you have kept the wiring short and the capacitor is a ceramic one and its a good quality switch. You are creating current pulses that may well peak at 5 A (without knowing the actual loop inductance and resistance, we can't predict closer than that). It could well look like a 10 MHz pulse train to neighbouring circuits, slower if there is more loop inductance. That is *guarenteed* mis-clocking and other trouble.

It needs as a *MINIMUM* a resistor between the switch common and the cap and another between the cap and the CMOS input to prevent any small ESD event dumping all the cap's charge into the protection diodes and frying the input. Even then it wont work as the '595 doesn't have Schmitt trigger inputs so its input acts as a high gain amplifier as it goes through its linear region and is either amplifying mV of noise into rail to rail pulses or just plain oscillating as it transitions. I last got bitten but this particular problem trying to clock a home-brew Z80 board back in the dark ages. The clock drive had to have VERY clean edges or it would skip apparently random instructions . . .

Lastly the classic SPDT switch debouncing circuit uses a SR flipflop. Either pick a flipflop with active low set and reset inputs, e.g. 7474 and tie all other inputs to their inactive state so the D type function is diabled and you are left with just SR or wire a quad 2 input NAND gate as a flipflop. Either give you two debouncers in one 14 pin chip. The moving contact goes to ground, the fixed contacts go to /S and /R with 1K to 10K pullups to +5V. Guaranteed to toggle cleanly and have good switch life.

The *preferred* debouncer for multiple individual buttons however is a Schmitt input buffer, a SPST switch and a R.R-C-R debouncer. (The switch grounds where the . is) which has one more resistor, (between the capacitor and the input) than Ganssle's fig.2 circuit to provide some ESD protection. Gansle recommends a 74xx14 and I see no reason to question that. You get more debounced inputs per chip and can use a wider range of cheaper switches. If you do a lot of breadboarding it would be worth building a set of debounced buttons on veroboard to avoid the hassle of assembling them each time.

Note that if you're feeding a microprocessor you may as well debounce in software, unless you just plain like using up board space.

I've done this, and it worked like a champ. It was a raw keyboard with about 64X spst contacts - wiring the 8X8 matrix was very tedious. I debounced for about 10 mS, and wrote a 16-key rollover. I was very proud. I used it on my TV typewriter. :-)

Cheers! Rich

If you sample the switch state every, say, 20 milliseconds, and act on what you see, there's no need to debounce at all.

John

__ +--o_ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |

=A0|

/R

he

id

Used dual 8x8 matrices on my MIDI pipe organ many years ago with NC / NO contacts to measure the 'fly time' and derive velocity. It was true N key rollover. Can't be missing notes in a performance. Contact debounce was looking for 3 consecutive scans (at 3kHz) of the new value. Worked very well.

G=B2

I am generally able to tell when, and usually am annoyed by, equipment sampling that way.

Jon

Just to support this comment, I do this all the time with software and very successfully. I use 4-8ms sampling periods and a simple state machine that takes 3 samples to settle. (For hardware, there are things like the MC14490 hex debouncer.)

I find debounced key events that take longer than 25ms to be annoying and increasingly so, very quickly. Snappy and consistently responsive is what I hope and look for.

I haven't studied it, but I would suppose that there are switch waveforms that would flummox any one specific software algorithm and where a general, well-designed hardware solution would work more broadly. Hardware is s-space and software is z-space. (So, if one knows, a priori, the sampling rate and phase of the software and its method it may be always possible to draw a seemingly realistic pattern that will provably screw up the software.) But I've never encountered a problem that a good software approach doesn't solve well.

Jon

If you have unwanted signals comparable to the clock rate of the processor on your switch waveform you almost certainly have an EMI problem not a bounce problem. Always test your circuit next to a ringing cellphone and make sure it at least fails safe :-)

There is always the SR in software approach. It takes one extra pin for a single switch or double the number of matrix rows and of course changeover switches. See the link I posted earlier.

Can you push a button for less than 20 milliseconds?

John

That's not exactly how I tell. And I can tell.

Jon

How can you tell that the software is sampling every 20 milliseconds if you can't push the button for less than that? Can you visually pick out the 50 Hz quantization of switch service, even assuming the associated display has instantaneous update?

And how can you tell a simple 20 ms sample loop from your 3-sample 8 ms debounce algorithm?

Maybe you could tell at 100 ms. Not at 20.

Debouncing is like bypassing. All sorts of weird religions exist.

John

Don't accuse me of being religious about this. It's experience with real products, doing beta testing in a lab. The programmer who'd used your technique told me how he'd written the code and I then knew what to do to show him. It was kind of funny to see his face, then.

Keep in mind you are talking about a single sample and acting upon it. That's the key. Not the 20ms period, which I consider fine. So stop focusing on that aspect and you might begin to see.

Jon

I don't know that his code "used my technique." Maybe he wrote a messy switch service routine. Lots of people do.

So what do you do to a pushbutton that can differentiate between a 20 ms single sample loop and a 3x8 ms debounce loop?

The only advantage of the multi-sample thing is some added EMI/ESD rejection. But ESD is a physical hazard to the uP, so if there's an ESD path it should be taken care of electrically.

John

Its fairly easy to hit a key fast enough so the uP doesn't respond if the debouncing is too 'clever' Even on this Cherry MX11900 keyboard, I can hit a key too fast for it to register. Not consistently, and it does require an aggressive wrist flick with a carefully aimed relaxed but extended finger so scarcely normal operation but it can be done about 20% of the time. The key is bottoming out fully so I'm not failing to make contact.

Actually, you bring up a good point. Not exactly the "messy" one, but another. I really don't have a full view of your method (you wrote simply, not fully) nor do I know the application space, switches used, etc. So I'm going on fumes, to be honest. The main thing, though, is the focus on using a single sample and acting on it. Not for every situation, but quite frequently in my experience this is a problem waiting to happen.

In the case I was referring to, the programmer used a timer to set the sampling event and I didn't even need to look at the code. I assumed he was right about what he told me and didn't assume he wrote crappy code (he was experienced with both c and assembly and had been working in instrumentation for years.) The hardware was designed by a very thorough-going guy (who is now working in the medical products field) who I would watch use a 20kV zap-gun and would run around the aluminum casing zapping everywhere to make sure it was pretty solid. It was. So I'm probably not confusing ESD sensitivity here. I had instantly imagined how to flummox the software and it took only a minute or two to get him to see problems happen. His situation was a simple, scanned 4x4 matrix using the method you talked about.

By the way, he'd tested his system and had encountered no problems in his own testing. He felt it was really pretty good. Until....

I don't consider acting on every 20ms observation 'solid.' And often, instrumentation developers "assume" a lot about how others might use their equipment and come away from their own testing feeling they have tested it well and the result is 'bullet proof.' In this guy's case, he felt really good about it. And when he saw me flummox it, he didn't argue with me about "well, no customer would do that!" He recognized immediately that some might do exactly "that." It had simply slipped by him to imagine the kinds of accidental things that actually happen in real situations.

Long, long ago I learned that the very small effort involved (and almost zero overhead in execution time) goes a long way mitigating such things. All from real experience and actual practice. Most of the time, no one notices the difference. But when it matters, it matters. Best to go the extra mile. It's really not hard and does mitigate a few after-sale calls that can cost some money to handle.

Not telling you what to do, though. Have at it. YMMV applies.

Jon

Interesting points.

Speaking of Cherry, I still have one of their really nice keyboards that uses reed relays under each and every switch and donut magnets in the key plungers. Absolutely rock solid. Damned if I can find anything like that being build, today.

Jon

Or you could hack into a $5.00 or surplus (free) PC keyboard:

Cheers! Rich

So what did you do to flummox it?

John