Hee hee, I knew that would, er, push someone's button. :)

So: consider the case where sampling occurs every 50 mS. A state change
occurs at time T, and causes 'bounce' for (we presume) no more than 50mS.

The next sample, S1, will occur at some time before T+50mS. The second
sample, S2, will occur sometime after T+50mS and is thus guaranteed a
steady state.

Therefore we only need to worry about S1, for which there are three
possibilities:

1-the input is stable in the new state.

2-the input is bouncing, but appears to have changed state.

3-the input is bouncing, but appears not to have changed state.

In cases 1 and 2, the state change is detected on S1. In case 2, the state
change is not detected until S2. The worst case detect time is 100 mS.

Now, if you're worried about NOISE, i.e. transient contacts due to
mechanical shock, button at the end of 200 feet of wire, etc. then you
need a low pass filter: the classical 'debounce' algorithm (yes, these
examples come from experience :)

But for switches right there on the PCB? Save the code, debounce not
required.

--- Rich




On Wed, 16 Feb 2000, Scott Dattalo wrote:

> Date: Wed, 16 Feb 2000 12:46:40 -0600
> From: Scott Dattalo <scott@DATTALO.COM>
> Reply-To: pic microcontroller discussion list <PICLIST@MITVMA.MIT.EDU>
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: debounce
>
> I'll cc this to the pic list since this thread is currently being
> discussed.
>
> On Wed, 16 Feb 2000, sep wrote:
>
> > Hi,
> > I think that your idea for debouncing the button is really cool. I am just a
> > little unsure of how to apply that to de-bouncing a switch directly.
> >
> > I am using the 16f84 and so I want to debounce 4 of the pins (a switch
> > attached on each). And then when the buttons are pressed to goto:
> >
> > button1touched
> > button2touched
> > button3touched
> > button4touched
> >
> >
> > Is there any snippets you have or any help you could give me. Sorry I am
> > just a beginner trying to get through these (probably easy) things!
> >
> > I appreciate your help.
>
>
> There are probably dozens of ways going about this. Let me pick the one
> I'd most probably choose. In most pic programs I write, there's usually an
> interrupt process (or several processes) like the TMR0 interrupt and then
> there's a foreground polling loop. The interrupt process responds as fast
> as possible to the needs of the hardware and does as little as possible.
> (Basically, just clear the pending interrupts and setting flags to notify
> the foreground that there's work to be done.) The foreground loop does the
> bulk of the work.
>
> Since you only have four switches, you only need four bits of the 8 bits
> in the variables used in the filters. I'd snatch one as a flag and do
> this:
>
>
> every 20 to 50 or so milliseconds (possibly in an interrupt routine),
> sample the I/O port that is attached to your switches. I'll assume that
> it's the lower four bits in PORTA:
>
>     movf   PORTA,w   ;Read the current switch setting
>     iorlw  0x80      ;Set the msb - this is 'we have data' flag
>     movwf  csa       ;This is the name of the variable used in
>                      ;the debounce routine
>
>
> Then within your main fore-ground loop
>
>     btfss  csa,7     ;If there's a sample, process it
>      goto  next_polled_item
>
>
> #ifndef RICH_LEGGIT  ; :)
>     call   de_bounce
> #else
>     movf   csa,w
>     movwf  cva
> #endif
>
>     bcf    csa,7           ;Clear the flag
>
>     movf   last_sample,w   ;get the previous sample
>     xorwf  cva,w           ;compare to the current
>     xorwf  last_sample,f   ;save the current sample as the last
>     andwf  last_sample,w   ;Monitor only changes that went high
>
>     movwf  temp
>
>     btfsc  temp,0
>      call  button1touched
>
>     btfsc  temp,1
>      call  button2touched
>
>     btfsc  temp,2
>      call  button3touched
>
>     btfsc  temp,3
>      call  button4touched
>
>
> The useful trick is:
>
> A ^ B ^ A = B
>
> Scott
>