ERIC SCHLAEPFER wrote, himself quoting Lawrence Lile:

>> Hmmm - this is why they tell you to never put a CLRWDT in a
>> subroutine - because if there was a stack underflow and the PIC
>> didn't see a CLRWDT in a long while the unit would reboot.

> I think so. It is also forces you to limit the size of your
> subroutines depending on the watchdog reset delay. (Is this good or
> bad?)

  No to the first, thence no to the second.  "They" might suggest you do
not put CLRWDT instructions in subroutines, and "they" may not.  If the
WDT times out, the stack pointer is reset (in fact, the only way of
doing it) along with the PC, but this has nothing to do with stack
overflow or underflow.

  The reason espoused for *not* putting CLRWDT in subroutines is simply
the recommendation that the instruction only appear in the code *once*.
This in turn is a "rule" to avoid the instruction appearing at so many
points in the code that an accidental terminal loop has a significant
probability of including a CLRWDT.

  So long as this rationale is understood, variations may be made.  If
in this case, you have a timing and input loop (much) longer than the
WDT period, then so be it.  You insert a single CLRWDT immediately
before the end of the outmost loop so that the WDT is reset just often
enough not to time out.  If this subroutine is always called at least as
often as the WDT period, then no other CLRWDT is required and there is
no problem.  If there is an alternate path within the main program loop,
then this will also need to contain a CLRWDT, possibly in an alternate
subroutine.

  As long as the routines containing the CLRWDT are few and simple
enough to be reckoned reliable, this should not be a problem.

  As to a "busy waiting" loop, these generally should have a single
return with a status returned in either W or a flag location, usually
zero (the loop index) or a keyvalue.

  Cheers,
        Paul B.