A couple of people have written: >After thoroughly answering Kat's basic question on watchdogs, Tjaart >wrote: > >> 3) a) Never (ever) tag the watchdog in more than one place >> in your program. If you do, you might as well leave it. > >I often use the CLRWDT instruction at the beginning of the main loop. > Are you implying that might not be the best place? > >I often am forced to use CLRWDT in the middle of long timing loops as >well. Many of my programs just "sit around" for seconds or minutes >at a time running a timing loop. Your statement indicates this might >be a bad idea. This is how ** I ** do it. Note: it works for me but my reasoning may be full of holes and I might be going about it all wrong also. Most of my projects make use of a background routine that is called repeatedly by main line code as well as any long subroutines. This background task maintains my real time clocks, reads and writes eeprom, handles the SPI ports, serial comms, reads and stores a/d results, reads and debounces external switches, etc. The watchdog is cleared as part of this background task. There is a bit of error checking before the clrwdt instruction is issued. In one version, the background waits for TMR0 to wrap - if it doesn't wrap, the watchdog times out. TMR0 is set at 1.024 mSec and is the basis of the real time clocks and the SPI data rate to off-board shift registers. The foreground task and any subroutines requiring long delays call the background task whenever they need to waste any time. If the PC gets corrupted or the thing goes off into lala land somewhere, the background does not get called, the watchdog times out, the pic resets. This works for code that is primarily time based (ie slow tasks). The nice thing about this is that most i/o is handled by the background task, which is code that has been thoroughly debugged over several years. Seems to work . . . dwayne Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (403) 489-3199 voice (403) 487-6397 fax