SPDT debounce doesn't

Sounds like a combination of bad switches, bad electronics (esd sensitivity) and bad code. So don't do that. A reasonable physical shock shouldn't cause a switch closure on a human interface panel.

If you sample every 20 milliseconds, and the switch bounce is less than, say, 10 milliseconds, it just works. If you catch it in the middle of a bounce, the state is exactly as ambiguous as if you did all the debouncing in the world. I've done this on all sorts of hard and membrane switches and it works as it should.

John

That looks like changing goal posts, to me. As I said, this comes from real experience with real equipment. I didn't design it. Switches vary a lot. And no, your argument that everything is exactly the same (ambiguous wise) no matter what you do in software doesn't make sense on its face. Software matters. And experience confirms.

Jon

You didn't look very hard:

I didn't mean "Cherry Corp." I meant "reed relay and ring magnets for each key." Can you point me to one, there? I'd appreciate it.

Thanks, Jon

What's kind of funny about this discussion (brings a smile to my face) is that I've never once had to discuss any of this with an electronics designer for longer than a few moments. Usually, they want to be sure _I_ am aware and will deal with it. So I'm actually enjoying the new experience you are affording me.

Did you read Ganssle's paper cited here in this thread by IanM? There are some modest scope diagrams there.

Jon

With a SPDT (see: subject) switch one can make the "perfect" debouncer. Don't need no steenkin' software. ;-)

A lot of pushbuttons, especially membranes, are SPST. Non-click-dome membranes often have absurd sliding/bouncing behavior.

John

I'm an EE who mostly does my own programming, so I usually don't have to collaborate with anybody to get things to work.

I'd seen that one before. It's not earth-shaking.

One way we debounce things in FPGAs is to clock the external state into an N-bit shift register, N=4 maybe, using the local system clock, sometimes divided down. If all SR bits are 1, set an RS flipflop; if all are 0, clear it. That's usually for stuff much faster than contact closures, like count inputs coming in from a customer or an asynchronous system that might have ringing or glitches.

John

Sure, but that wasn't the OP's question. For membranes I usually just double sample, pretty much like any other asynchronous interface.

Good response! But I had been discussing a reply that brought in the subject of _software_.

Jon

EE's almost cannot get along without developing such skills, anymore, it seems. Too often a damned lot better than many embedded programmers without electronics knowledge. ;) I think it's a mark of excellence that you do the hands-on whether often or from time to time.

Jon

Yup, I agreed, people you don't need any IC, RC circuit to debounce a contact, all you need is a C+R That's it. Life is complicated enough why complicate yourself more ? These two part won't cost you more than 7 cents. Only dumbasses need a circuit board to debounce their shit.....heehee.....

What if you are not integrating with a software then dambass? Your idea won't work.

FLUSH!

Hey John lackin, listen up, you are going to miss seeing the impulse if your software is dragged down by heavy task, especially in embedded system, equipped with slow CPU, don't say it won't happen, it happens all the time. Debouncing through hardware is the best solution, so your software can see wider impulse Stupid! You and John Fools are too goofy in your shitty brains.

equipped

I have built systems for over 30 years. We have never bothered doing hardware debouncing. Switches are sampled in a regular timer interrupt service routine. With this scheme, you can do whatever debouncing scheme that you want. You can also latch contact closures so that they can be processed whenever desired. We built systems using 8080s with a few Mhz clock rates with no problems.

Only an extremely poorly designed piece of equipment would miss contact closures if you are sampling them with a timer interrupt. (You would have to be missing entire interrupt service requests and this would mean that you have major problems.)

All I ever did was disable the INT after each trigger for a short period via a timer.. On each INT trigger, I just disabled it, and then at the end of the ISR, initiate a timer for that ISR, I simply tested to see how it was configed each time it entered the ISR handler and alternated its state.

This all was done in a single ISR handler instead of making two different ISRs. The uC wouldn't get flooded this way with deboucing issues.

Why would a periodic IRQ fail to run because the operate side was doing stuff?

You have heard of interrupts?

Show us something you've designed.

John

Dambass? Are you cursing a fish or cursing a beer?

But it does work.

Show us something you've designed.

John

This happens automatically on any good processor; returning from the interupt service routine reenables automagically.

Do you have one ISR to do two different things, or are there two interrupts to initiate the same task?

Thanks, Rich