Searching \ for 'General switch debounce questions' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=general+switch+debounce
Search entire site for: 'General switch debounce questions'.

Truncated match.
PICList Thread
'General switch debounce questions'
1999\03\08@115158 by Dan Larson

flavicon
face
I am about to add some pushbutton switches to my Pic'bot
design that will be read from a shift register 74HC597.

(Did I get the right part?  I don't have my data sheets
with me.  Its either the 595 or 597.... Anyway I am talking
about the parallel in to serial out shift register...)

My question is:

Considering that I am reading the buttons through the shift
registers (two cascaded for 16 input bits) what sort of
debouncing algorithms should I use?  I am not asking
for code, just the algorithm.  Code would be OK, by I can
write my own code so an explanation would be better.

TIA!

Dan

1999\03\08@115956 by Scott Dattalo

face
flavicon
face
On Mon, 8 Mar 1999, Dan Larson wrote:

> I am about to add some pushbutton switches to my Pic'bot
> design that will be read from a shift register 74HC597.
>
> (Did I get the right part?  I don't have my data sheets
> with me.  Its either the 595 or 597.... Anyway I am talking
> about the parallel in to serial out shift register...)
>
> My question is:
>
> Considering that I am reading the buttons through the shift
> registers (two cascaded for 16 input bits) what sort of
> debouncing algorithms should I use?  I am not asking
> for code, just the algorithm.  Code would be OK, by I can
> write my own code so an explanation would be better.

Check out:

http://www.interstice.com/~sdattalo/technical/software/pic/debounce.html

I think this will be suitable for your application since it (the
debounce program) is designed to debounce several (8) inputs in parallel.

Scott

1999\03\08@142502 by Gerhard Fiedler

picon face
At 10:46 03/08/99 +0600, Dan Larson wrote:
>I am about to add some pushbutton switches to my Pic'bot
>design that will be read from a shift register 74HC597.
>
>(Did I get the right part?  I don't have my data sheets
>with me.  Its either the 595 or 597.... Anyway I am talking
>about the parallel in to serial out shift register...)
>
>My question is:
>
>Considering that I am reading the buttons through the shift
>registers (two cascaded for 16 input bits) what sort of
>debouncing algorithms should I use?  I am not asking
>for code, just the algorithm.  Code would be OK, by I can
>write my own code so an explanation would be better.

that's the 597, and if i read that data sheet right, it has got the same
problem with cascading as all shift registers: it changes its output on the
same (the rising) edge as it samples the input, which leads to a possible
timing violation of the data hold time at the serial input. which may work
or not, depending on the numbers of butterflies awake in china :)  since
the min. data hold time for the serial in is usually much lower than the
max. propagation delay shift clock to serial out, it probably works more
often than not, but it still feels shaky...

or am i wrong here?

ge

1999\03\08@152454 by Wagner Lipnharski

picon face
Gerhard Fiedler wrote:
> that's the 597, and if i read that data sheet right, it has got the same
> problem with cascading as all shift registers: it changes its output on the
> same (the rising) edge as it samples the input, which leads to a possible
> timing violation of the data hold time at the serial input. which may work
> or not, depending on the numbers of butterflies awake in china :)  since
> the min. data hold time for the serial in is usually much lower than the
> max. propagation delay shift clock to serial out, it probably works more
> often than not, but it still feels shaky...
>
> or am i wrong here?
>
> ge

Gerhard, you made me think, and looking at the circuit function, it
looks
like that the shift out bit follows the same timing from the internal
shifting Q = Q - 1, so, it means, that when clock goes up, Q copies the
(old and stable) state from Q-1, but the internal propagation is lazy
and it takes time to set Q = Q-1, so Q-1 state does not propagate to Q+1
at the same raise clock pulse.  Happens the same at the last shifted
bit,
the shift out. It means that when you clock up, the serial in of the
chip
#2 will just copy the actual (old) state of the shift out chip #1, and
then it will update the latches.  First all cells gate Q=Q-1 then the
real update happens. If this works internally, will work externally too.
Now, am I wrong here too? :)
--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:   http:/http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\03\08@153108 by Wagner Lipnharski

picon face
just updating information:
In the Texas CD74HCT597 data sheet, what avoids Q+1=Q-1
in the same cycle, is the timing tPLH (60ns).
Take a look at (page 8):
www-s.ti.com/sc/psheets/schs191/schs191.pdf
--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:   http:/http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\03\08@175023 by Gerhard Fiedler

picon face
At 15:30 03/08/99 -0500, Wagner Lipnharski wrote:
>just updating information:
>In the Texas CD74HCT597 data sheet, what avoids Q+1=Q-1
>in the same cycle, is the timing tPLH (60ns).
>Take a look at (page 8):
>http://www-s.ti.com/sc/psheets/schs191/schs191.pdf


yes, that's why i think it =usually= might work. but in the same place
there is a Th(h), the minimum data hold time. i didn't find a spec on that
in this texas sheet, but in the motorola data sheet
http://www.mot-sps.com/books/dl129/pdf/mc74hc597rev6.pdf it is spec'd with
min 5ns. this means it works as long as the propagation delay is not
shorter than 5ns, which seems not to be specified.

i seem to recall some discussion on this here; does anybody have
experiences with a problem with chaining shift registers?

ge

1999\03\08@175850 by Sean Breheny

face picon face
Hi Dan,et al,

I think what Dan is getting at (correct me Dan if I'm wrong) is not how to
do debouncing,but how to handle debouncing when you are reading a switch
thru a shift reg,instead of directly.

I think the answer to this is that you must do lots of shifts! You can
still sample the button very quickly,it just involves shifting the reg a
lot. If not all of the things being read thru the shift reg need to be
debounced,then you might consider placing the inputs that DO need to get
debounced closer to the end which shifts out first,thereby requiring fewer
shifts per sample.

Hope this helps,

Sean

At 10:46 AM 3/8/99 +0600, you wrote:
{Quote hidden}

| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
spam_OUTshb7TakeThisOuTspamcornell.edu ICQ #: 3329174

1999\03\08@181316 by Wagner Lipnharski

picon face
Gerhard Fiedler wrote:
>
> At 15:30 03/08/99 -0500, Wagner Lipnharski wrote:
> >just updating information:
> >In the Texas CD74HCT597 data sheet, what avoids Q+1=Q-1
> >in the same cycle, is the timing tPLH (60ns).
> >Take a look at (page 8):
> >http://www-s.ti.com/sc/psheets/schs191/schs191.pdf
>
> yes, that's why i think it =usually= might work. but in the same place
> there is a Th(h), the minimum data hold time. i didn't find a spec on that
> in this texas sheet, but in the motorola data sheet
> http://www.mot-sps.com/books/dl129/pdf/mc74hc597rev6.pdf it is spec'd with
> min 5ns. this means it works as long as the propagation delay is not
> shorter than 5ns, which seems not to be specified.
>
> i seem to recall some discussion on this here; does anybody have
> experiences with a problem with chaining shift registers?
>
> ge

Well, yes, they don't specify even the minimum propagation time,
so supposing that in China there are always more butterflies
flying than resting, it will works (if not otherwise observed).
I already did some cascades and never got a problem, well not
with the 597, but other works fine.
wagner.

1999\03\09@094921 by mlsirton

flavicon
face
Hi all,

On  8 Mar 99 at 11:18, Gerhard Fiedler wrote:
<snip>
> At 10:46 03/08/99 +0600, Dan Larson wrote:
<snip>
> >debouncing algorithms should I use?  I am not asking
> >for code, just the algorithm.  Code would be OK, by I can
> >write my own code so an explanation would be better.

The problem you are trying to solve is that while a switch is
changing position it will "bounce" between on and off for a short
period of time (depending on the nature of the switch used).
The easiest solution is to read the switch(es) in a loop and perform
the action only if all the readings are the same.  This will
eliminate any bounces that are as long as the loop time.

e.g. (simplistic C pseudo-code)
instead of:
if(button) action;
this will debounce:
b = 1; for(i=0; i<N; i++) b &= button; if(b) action;

You can get fancier but for most applications something simple like
this will do.

For doing the 16 buttons at once you could:
1. read buttons into buffer (2 bytes)
2. do N times
3.    read buttons and compare to buffer
4.    if not equal return
5. end
6. perform actions based on button data in buffer

This will debounce all buttons but if one button bounces it will
ignore all the other buttons - for most apps this isn't a problem.

> that's the 597, and if i read that data sheet right, it has got the same
> problem with cascading as all shift registers: it changes its output on the
> same (the rising) edge as it samples the input, which leads to a possible
> timing violation of the data hold time at the serial input. which may work

To avoid the cascading problem you could use two input pins for the
two shift registers (clock and load them both from the same outputs)
if you have a pin to spare. (You can also delay the clock to the
second shift register with an R/C network).

Hope this helps,
Guy

1999\03\09@122448 by Mike Keitz

picon face
On Tue, 9 Mar 1999 16:43:02 +0000 Guy Sirton <.....dansoftKILLspamspam@spam@MAIL.INTER.NET.IL>
writes:
>Hi all,
>
>On  8 Mar 99 at 11:18, Gerhard Fiedler wrote:
><snip>
>> At 10:46 03/08/99 +0600, Dan Larson wrote:
><snip>
>> >debouncing algorithms should I use?  I am not asking
>> >for code, just the algorithm.  Code would be OK, by I can
>> >write my own code so an explanation would be better.
>
>The problem you are trying to solve is that while a switch is
>changing position it will "bounce" between on and off for a short
>period of time (depending on the nature of the switch used).

There are many different ways to deal with switch bounce.  Perhaps the
simplest is just to poll the switch slowly.  If your polling interval is
longer than the maximum bounce time, the output can always be trusted.
The main problem with this method is that there is a relatively long and
variable time to respond to the switch changing.  If the switch is
operated manually, it usually won't be noticeable.  This method is
entirely suitable for many applications.

If the switches are part of a machine for example, a fast reaction to
changes would be good.  Consider reacting to the switch as soon as it
changes, but then ignore further changes during the bouncing interval.
This method gives fast response, but requires a "timer" for each switch.

Both of the methods above, especially the second, are sensitive to pulses
of noise on the switch inputs.  Though this isn't strictly switch bounce,
a routine intended to handle switch bounce can also serve to reject
noise.  Polling several times and looking for a majority or unanimous
decision will reject pulses of noise that are shorter than the polling
time.  But it will extend the response time until a decision is made.  In
a highly optimized scheme, a decision could be made while the switch is
still bouncing.  Then a timer would be used to ignore the switch until
the bounce time is over.



___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\03\09@145154 by John Payson

flavicon
face
|There are many different ways to deal with switch bounce.  Perhaps the
|simplest is just to poll the switch slowly.  If your polling interval is
|longer than the maximum bounce time, the output can always be trusted.
|The main problem with this method is that there is a relatively long and
|variable time to respond to the switch changing.  If the switch is
|operated manually, it usually won't be noticeable.  This method is
|entirely suitable for many applications.

|If the switches are part of a machine for example, a fast reaction to
|changes would be good.  Consider reacting to the switch as soon as it
|changes, but then ignore further changes during the bouncing interval.
|This method gives fast response, but requires a "timer" for each switch.

One approach which works well for both switches and sensors, at some
expense in time/memory, is to have associated with each switch both a
bit indicating its "believed" state and a byte used as a sort of timer.
The code looks something like this:

char switch_time;
bit switch_value;

{
 if (INPUT)
 {
   if (switch_time >= 100)
     switch_value = 1;
   else
     switch_time++;
 }
 else
 {
   if (switch_time)
     switch_time--;
   else
     switch_value = 0;
 }
}

If the switch changes states cleanly, the output will be delayed by a
consistent amount.  If the switch does not change states cleanly, the
output will be delayed somewhat longer.  If the input is connected to a
sensor which goes from being on 52% of the time to only being on 49% of
the time, the output will take a long time to switch, but it eventually
will and it will do so cleanly.

There are many ways of writing or adapting the above algorithm; for what
it does, though, it works very well.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...