SPDT debounce doesn't

[Jon Kirwan]

On Thu, 03 Dec 2009 15:21:33 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 11:26:42 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

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

Jon

Can you push a button for less than 20 milliseconds?

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.

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.

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

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.

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.

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.

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

So what did you do to flummox it?

There's no magic involved. Touch and bump and drop (like a user
might, placing the equipment quickly onto a table or brushing by
someone and the equipment or....) Observation does depend on what
action software takes, obviously. If it takes no action, there's no
problem to observe. Bear in mind that your sample event might be
..1 or 1 or 10 or 100 or almost any number of microseconds after a bump
event... the sampling is entirely asynchronous to the real world and
the switch contact physics, as you know. And you are saying the
software should take action, regardless. As I understand you.

Jon

 

[John Larkin]

On Thu, 03 Dec 2009 15:59:29 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 15:21:33 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 11:26:42 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

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

Jon

Can you push a button for less than 20 milliseconds?

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.

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.

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

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.

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.

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.

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

So what did you do to flummox it?

There's no magic involved. Touch and bump and drop (like a user
might, placing the equipment quickly onto a table or brushing by
someone and the equipment or....) Observation does depend on what
action software takes, obviously. If it takes no action, there's no
problem to observe. Bear in mind that your sample event might be
.1 or 1 or 10 or 100 or almost any number of microseconds after a bump
event... the sampling is entirely asynchronous to the real world and
the switch contact physics, as you know. And you are saying the
software should take action, regardless. As I understand you.

Jon

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

 

[Jon Kirwan]

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 15:59:29 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 15:21:33 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 13:13:36 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 11:26:42 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 10:51:02 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

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

Jon

Can you push a button for less than 20 milliseconds?

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.

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.

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

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.

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.

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.

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

So what did you do to flummox it?

There's no magic involved. Touch and bump and drop (like a user
might, placing the equipment quickly onto a table or brushing by
someone and the equipment or....) Observation does depend on what
action software takes, obviously. If it takes no action, there's no
problem to observe. Bear in mind that your sample event might be
.1 or 1 or 10 or 100 or almost any number of microseconds after a bump
event... the sampling is entirely asynchronous to the real world and
the switch contact physics, as you know. And you are saying the
software should take action, regardless. As I understand you.

Jon

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.

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

 

[Michael A. Terrell]

Jon Kirwan wrote:

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.

You didn't look very hard:
<http://www.cherrycorp.com/english/keyboards/Industrial/index.htm>


--
The movie 'Deliverance' isn't a documentary!

 

[Jon Kirwan]

On Thu, 03 Dec 2009 21:28:30 -0500, "Michael A. Terrell"
<mike.terrell@earthlink.net> wrote:

Jon Kirwan wrote:

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.


You didn't look very hard:
http://www.cherrycorp.com/english/keyboards/Industrial/index.htm

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

 

[Jon Kirwan]

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
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.
snip

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

 

[krw]

On Thu, 03 Dec 2009 18:52:30 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
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.
snip

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.

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

 

[John Larkin]

On Thu, 03 Dec 2009 22:12:21 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:

On Thu, 03 Dec 2009 18:52:30 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
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.
snip

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.

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

 

[John Larkin]

On Thu, 03 Dec 2009 18:52:30 -0800, Jon Kirwan
<jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
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.
snip

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.

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.

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

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

 

[krw]

On Thu, 03 Dec 2009 20:25:30 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 22:12:21 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:

On Thu, 03 Dec 2009 18:52:30 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
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.
snip

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.

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.

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

 

[Jon Kirwan]

On Thu, 03 Dec 2009 22:12:21 -0600, krw <krw@att.bizzzzzzzzzzz> wrote:

On Thu, 03 Dec 2009 18:52:30 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
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.
snip

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.

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

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

Jon

 

[Jon Kirwan]

On Thu, 03 Dec 2009 20:43:31 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

On Thu, 03 Dec 2009 18:52:30 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Thu, 03 Dec 2009 17:01:24 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
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.
snip

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.

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.

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

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

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.

 

[Edmond Wollmann]

"Rich Grise" <richgrise@example.net> wrote in message
newsan.2009.12.01.21.36.38.506991@example.net...

On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott wrote:
On Tue, 01 Dec 2009 10:48:18 +0000, IanM wrote:

Jasen Betts wrote:
+5v
+-----------------------------+----
| ____|________ +--o_ |
|
-_ 11| 74hc595 |
-o--+-------------[| |
| |____________|
+--o === 100nF |
| | |
0v+----------+------------------+


I've been told the left part of the ciecuit is a good way to debounce a
switch but I'm seing on the outputs what appears to be contact bounce.

the the switch is a mini microswitch
there are several 1uF MLCCs across the supply construction is on
solderless breadboard

adding an active debounce using a 555 seems to solve it

can anyone explain what's going on?
Yep. but Jack G. Ganssle does it much better. Read
http://www.ganssle.com/debouncing.pdf
...
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

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.....

 

[Edmond Wollmann]

"John Lackin" <jjlackin@highNOTlandTHIStechnologyPART.com> wrote in message
news:kjobh55hr1ml18d0eigq9ooigmrmgerfos@4ax.com...

On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Tue, 01 Dec 2009 10:48:18 +0000, IanM wrote:

Jasen Betts wrote:
+5v
+-----------------------------+----
| ____|________ +--o_ |
|
-_ 11| 74hc595 |
-o--+-------------[| |
| |____________|
+--o === 100nF |
| | |
0v+----------+------------------+


I've been told the left part of the ciecuit is a good way to debounce a
switch but I'm seing on the outputs what appears to be contact bounce.

the the switch is a mini microswitch
there are several 1uF MLCCs across the supply construction is on
solderless breadboard

adding an active debounce using a 555 seems to solve it

can anyone explain what's going on?
Yep. but Jack G. Ganssle does it much better. Read
http://www.ganssle.com/debouncing.pdf

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.

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

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



FLUSH!

 

[Edmond H. Wollmann]

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:2k3eh5lsso6nmcoejtpdq8aea5atv6thc2@4ax.com...

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

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

Jon

Can you push a button for less than 20 milliseconds?

John

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.

 

[Dan Coby]

Edmond H. Wollmann wrote:

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:2k3eh5lsso6nmcoejtpdq8aea5atv6thc2@4ax.com...
On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

snip
If you sample the switch state every, say, 20 milliseconds, and act on
what you see, there's no need to debounce at all.
I am generally able to tell when, and usually am annoyed by, equipment
sampling that way.

Jon
Can you push a button for less than 20 milliseconds?

John


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.

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.)

 

[Jamie]

Dan Coby wrote:

Edmond H. Wollmann wrote:

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
message news:2k3eh5lsso6nmcoejtpdq8aea5atv6thc2@4ax.com...

On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

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

Jon

Can you push a button for less than 20 milliseconds?

John



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.


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.

 

[John Larkin]

On Sun, 6 Dec 2009 22:25:05 -0800, "Edmond H. Wollmann"
<EHWollmann@aol.com> wrote:

"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message
news:2k3eh5lsso6nmcoejtpdq8aea5atv6thc2@4ax.com...
On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
jonk@infinitefactors.org> wrote:

On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

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

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

Jon

Can you push a button for less than 20 milliseconds?

John


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.

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

 

[John Larkin]

On Sun, 6 Dec 2009 22:14:01 -0800, "Edmond Wollmann"
<EHWollmann@aol.com> wrote:

"John Lackin" <jjlackin@highNOTlandTHIStechnologyPART.com> wrote in message
news:kjobh55hr1ml18d0eigq9ooigmrmgerfos@4ax.com...
On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott <tim@seemywebsite.com
wrote:

On Tue, 01 Dec 2009 10:48:18 +0000, IanM wrote:

Jasen Betts wrote:
+5v
+-----------------------------+----
| ____|________ +--o_ |
|
-_ 11| 74hc595 |
-o--+-------------[| |
| |____________|
+--o === 100nF |
| | |
0v+----------+------------------+


I've been told the left part of the ciecuit is a good way to debounce a
switch but I'm seing on the outputs what appears to be contact bounce.

the the switch is a mini microswitch
there are several 1uF MLCCs across the supply construction is on
solderless breadboard

adding an active debounce using a 555 seems to solve it

can anyone explain what's going on?
Yep. but Jack G. Ganssle does it much better. Read
http://www.ganssle.com/debouncing.pdf

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.

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




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

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

But it does work.

http://www.highlandtechnology.com/DSS/P400DS.html

Show us something you've designed.

John

 

[Rich Grise]

On Mon, 07 Dec 2009 20:13:53 -0500, Jamie wrote:

Dan Coby wrote:
Edmond H. Wollmann wrote:
"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin

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

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

Can you push a button for less than 20 milliseconds?

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.

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..

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

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.

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

Thanks,
Rich