Sidare, Matthew <PICLIST@mitvma.mit.edu> wrote:

> I've used a software integrating switch debouncer with great success.
>
> I got it from a book by Fredrik M. Cady "Microcontrollers and
> Mocrocomputers" [ISBN: 0-19-511008-0] (A book from college that I used
> at work!)
>
> Pseudocode:(modified from book)
>
> INITIALIZE REGISTER count=128
> WHILE (count >0 and count<255)
>    DO
>         DELAY 1 milisec
>       Get Switch Input
>       IF Switch open
>          THEN increment count
>            ELSE decrement count
>         ENDIF
>    ENDO
> ENDWHILE
> IF count=0
>    THEN Switch is closed
>    ELSE Switch is open
> END IF

    If the purpose of a "debounce" routine is to report a switch's
    state only after it's settled into that state for some specified
    period of time, this code doesn't work.

    Think about what happens when you feed Cady's code a 50%
    duty-cycle signal that NEVER STOPS bouncing.  It won't ever say
    that the switch is debounced in one state or the other (which is
    correct), but it'll never get out of the WHILE loop, either; your
    PIC will be stuck there forever.

    Now think about what happens when you change the duty-cycle to,
    for example, 1.01 milliseconds closed, 1 millisecond open.  The
    signal never stops bouncing, but Cady's code will incorrectly
    report it debounced after 12-25 seconds or so.

    Finally, consider the case in which a rock-solid non-bouncing
    switch is filtered by the code.  At the very LEAST, the code
    should be able to handle THAT case properly, right?  Ok, how
    long is the debounce time?  Bet you can't specify it to within
    even 50 milliseconds.

    -Andy

=== Andrew Warren -- aiw@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu