I would suspect because debouncing goes for both pressing and releasing the
button. The debounce routine will also work as a filter for the input and
reject pulses that are too short.

"addlw not permitted" - Just check if the PIC family is 12bit or 14bit duri=
ng
compile time and use the most efficient way with conditional compilation.

/Ruben


> Hi Dwayne,
>=20
> Why are you counting up and down too? It seems to me counting and clear
> could give you a smaller code snipplet.
>=20
> _BEGIN_LOOP_
>=20
> _NOT_YET_EITHER_HERE_
>=20
>     ; 5 cycl * 1us * 256 =3D 1.28ms
>     ; call _DELAY_ ; you may need this
>=20
>     btfsc  _BTN_
>     clrf   _BTN_CNT_
>     decfsz _BTN_CNT_,f
>     goto   _NOT_YET_
>=20
> _BUTTON_PRESSED_
>     ...
>=20
> _NOT_YET_EITHER_THERE_
>     ...
>     goto _BEGIN_LOOP_
>=20
>=20
> Tamas
>=20
>=20
>=20
>=20
> On 7 October 2014 16:30, Dwayne Reid <dwayner@planet.eon.net> wrote:
>=20
> > Good day to all.
> >
> > I'm revisiting an old project that runs in a 12F508 12-bit core
> > PIC.  There is one particular code segment that I use in many
> > projects that I'd like suggestions on.
> >
> > This is a simple debounce timer that uses a single byte as a counter
> > that increments or decrements depending on the input.  This version
> > uses all 8 bits (255 counts) but I do similar versions that run
> > smaller bit lengths - 5, 6, 7 bits - depending on how much debounce
> > time I want.
> >
> > The main counting part of the code sits in my timer background task
> > which gets called every 1024 us - the PIC runs at 1us instruction
> > rate and I have TMR0 set with a /4 prescaler.
> >
> > The limit test portion of the debounce code normally sits in
> > main-line code and the counter limits are tested as needed.  However,
> > for this project, its easier if I have the limit test also sitting in
> > the timer background task.  That way, my main line code only has to
> > test a flag rather than having to test the counter.
> >
> > The counter counts up and down from 0x01 through 0xFF.  "0" is a
> > disallowed value.  Counters are initialized to either 0x01 or 0x80,
> > depending on the job the counter is doing.
> >
> > Enough verbage.  Some definitions: MODE_TMR is a 1-byte counter,
> > _MODE is the input being tested, _MODE_F is the flag bit that gets
> > set or cleared whenever the counter reaches the upper or lower bound.
> >
> > Main counter section is as follows:
> >
> > ;button debounce    ;8 bit counter: 255 ticks to wrap up or down
> >      incf        MODE_TMR,W
> >      btfss       _MODE           ;btfss=3DactiveHI, btfsc=3DactiveLO
> >        decf      MODE_TMR,W
> >      skpz                        ;if at either min or max, Z=3D=3D1
> >        movwf     MODE_TMR        ;  *don't* write to counter
> > ;Z=3D1 if cntr at min or max value
> >
> > In most projects, I use the following snippets of code in the main
> > code body to test the counter limits:
> >
> > ;;use the following snippets to test button in foreground task:
> > ;;    incfsz      SB_TMR,W        ;if cntr NOT 0xFF
> > ;;      goto      button was not pressed
> > ;;
> > ;;    decfsz      SB_TMR,W        ;if cntr NOT 0x01
> > ;;      goto      button was not released
> >
> > Note that I don't need any flags with the above snippets - the
> > counter is tested and acted upon immediately.  The other advantage of
> > the above snippets is that the status bits Z, C, DC don't get
> > touched.  This can simplify the code that the snippets are part of.
> >
> > However, for this project, I want to test the counter within the
> > background timer task.  This is the code that I'm currently using:
> >
> >      incfsz      MODE_TMR,W      ;if cntr NOT 0xFF
> >        goto      $+2
> >      bsf         _MODE_F
> >      decfsz      MODE_TMR,W      ;if cntr NOT 0x01
> >        goto      $+2
> >      bcf         _MODE_F
> > <end of copy>
> >
> > The total routine occupies 11 code spaces: 5 code words for the
> > counter update routine and 6 code words for the limit test and flag
> > set/clear.
> >
> > My question for the group is: Is there a better way to do this?  This
> > needs to run in both the 12-bit and 14-bit core PICs, which means
> > that op-codes such as 'addlw' are not permitted.
> >
> > Many thanks!
> >
> > dwayne
> >
> > --
> > Dwayne Reid   <dwayner@planet.eon.net>
> > Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
> > (780) 489-3199 voice          (780) 487-6397 fax
> > www.trinity-electronics.com
> > Custom Electronics Design and Manufacturing
> >
> > --
> > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
>=20
>=20
>=20
> --=20
> int main() { char *a,*s,*q; printf(s=3D"int main() { char *a,*s,*q;
> printf(s=3D%s%s%s, q=3D%s%s%s%s,s,q,q,a=3D%s%s%s%s,q,q,q,a,a,q); }",
> q=3D"\"",s,q,q,a=3D"\\",q,q,q,a,a,q); }
> --=20
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ruben J=F6nsson
AB Liros Electronic
Box 9124
200 39 Malm=F6 Sweden
www.liros.se
Tel +46 40142078
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.