> > Hi Olin

<snipped short intro for routine>

> > _Debounce4
> >           movlw      0x64
> >           movwf      countOn
> >           movwf      countOff
> >           btfsc         PORTA,4
> >           decfsz     countOn,f
> >           goto         $ + 0x02
> >           goto         A4On
> >           decfsz     countOff,f
> >           goto         $ - 0x05
> > A4Off
> >            bcf            aFlag,4
> >            goto         $ + 0x02
> > A4On
> >            bsf           aFlag,4
> >            retlw        0x00
> > regards
> >    Ollie Wallock

<snipped reflex response to unsolicted private mail, and extreme criticism
of code, student and teacher>

First off, I agree that this code should be commented and the relative
goto's are unnecessary.  Whilst this may be a "cutesy" way to debounce a
button, it suffers from several inherent flaws, IMHO:

1)  There is no time base.  IOW, this code is dependant upon clock speed.
Fast crystals and dirty switches will be the demise of this routine.

2)  Single threaded and indeterminate.  There is no way to calculate the
length of time that this will execute.  As a rough guess, it looks like this
could take more than a millisecond to execute (w/4Mhz clock) in the worst
case.  This may be fine for some applications, but polling switches this way
is sometimes impractical.  This is allot of time to spend just testing one
switch, and then not being able to do anything else during the time period.

It would be better (faster) if the A4Off section just did a "return" instead
of the goto.  The "retlw" instruction seems to be somewhat pointless since
returning a zero in either case means nothing to the upper level code.
Perhaps he could return the opposite states counter for tolerance checking
by the upper code.  For example, if the returned value is "close" to zero,
then the switch must have bounced a great deal and perhaps it should be
polled again.  Although, I doubt this would be very useful in real world
applications.

A RAM location could be saved by starting the counter at 128 and then
incrementing when the pin tests high, decrementing when it tests low.  When
zero is reached, the state is then known.

Generally, I prefer the timer-loop ISR method to debounce switches.  I
believe it to be the most robust and reliable way, since you can pick any
arbitrary length of time (say 50ms - 3000ms) to debounce it, without
spending the entire time spinning around in the debounce routine.

michael brown

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics