Dan Creagan wrote:

> This could be done in the main program or as an interrupt.  If your
> program is just ticking over waiting for the switch, then it doesn't
> need the interrupt.  If you are doing magnificent things with the chip
> while you are waiting for the switch, then set the switch on an
> external interrupt.

  Just on a philosophical note, I see it the other way round!  Do by all
means put the switch on an interrupt line - unless the interrupt is
needed by something important!  However, if the program is "just ticking
over waiting for the switch" it could just as easily be sleeping.  And
you don't even need an interrupt for that as it could be periodically
waking by the watchdog and polling the switch.

  If OTOH "you are doing magnificent things with the chip" in the
meantime, then you really don't need an interrupt for the switch and in
fact, an interrupt would be more of an embarrassment as it will occur
while the "magnificent things" are in mid-stride.

  At the speed of a microprocessor, a human-interfaced switch is a
trivial and imprecise matter.  The loop (there's always a loop!) running
your magnificent task will in the vast majority of cases have a
predictable duration within 50% and that will be a sufficient timebase
for your debounce and long/ short discrimination.

  As well, many applications will have a timer "tick" generated by the
TMR0/ prescaler *either* polled or under interrupt, and this routine can
poll the switch.

  I think this is significant as while the program *might* do nothing
more than wait for a switch and activate an output, there is invariably
something else useful it might do in the meantime ("software creep").

  Also, just because the chip *provides* interrupts does not make them
appropriate in any application (especially in PICs!).
--
  Cheers,
        Paul B.