From: IanM on
Jon Kirwan wrote:
> On Tue, 01 Dec 2009 13:23:57 -0600, Tim Wescott <tim(a)seemywebsite.com>
> wrote:
>
>> <snip>
>> Note that if you're feeding a microprocessor you may as well debounce in
>> software, unless you just plain like using up board space.
>
> 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.)
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 :-)

> But I've never encountered
> a problem that a good software approach doesn't solve well.
>
> Jon

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.

--
Ian Malcolm. London, ENGLAND. (NEWSGROUP REPLY PREFERRED)
ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
[at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails --> NUL:
From: John Larkin on
On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
<jonk(a)infinitefactors.org> wrote:

>On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
><jjlarkin(a)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

From: Jon Kirwan on
On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
<jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:

>On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
><jonk(a)infinitefactors.org> wrote:
>
>>On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
>><jjlarkin(a)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
From: John Larkin on
On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
<jonk(a)infinitefactors.org> wrote:

>On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:
>
>>On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
>><jonk(a)infinitefactors.org> wrote:
>>
>>>On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
>>><jjlarkin(a)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.

John

From: Jon Kirwan on
On Thu, 03 Dec 2009 08:51:55 -0800, John Larkin
<jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:

>On Wed, 02 Dec 2009 19:36:56 -0800, Jon Kirwan
><jonk(a)infinitefactors.org> wrote:
>
>>On Wed, 02 Dec 2009 17:04:40 -0800, John Larkin
>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote:
>>
>>>On Wed, 02 Dec 2009 14:03:58 -0800, Jon Kirwan
>>><jonk(a)infinitefactors.org> wrote:
>>>
>>>>On Tue, 01 Dec 2009 19:45:21 -0800, John Larkin
>>>><jjlarkin(a)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.

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