home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / realtime / 1044 < prev    next >
Encoding:
Text File  |  1992-09-03  |  1.4 KB  |  30 lines
  1. Newsgroups: comp.realtime
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!griest
  3. From: griest@ajpo.sei.cmu.edu (Tom Griest)
  4. Subject: Re: Where to stick the watchdog ?
  5. Message-ID: <1992Sep3.164554.15410@sei.cmu.edu>
  6. Keywords: kernals watchdog 
  7. Sender: Tom Griest
  8. Organization: Software Engineering Institute
  9. References: <1992Sep03.034229.13095@crs-sys.uucp>
  10. Date: Thu, 3 Sep 1992 16:45:54 GMT
  11. Lines: 17
  12.  
  13. In article <1992Sep03.034229.13095@crs-sys.uucp> crs@crs-sys.UUCP (Chris Gregors) writes:
  14. >Recently I had an argument (discussion) with some co-workers regarding where
  15. >is an appropriate place to kick a watchdog timer inside an application program.
  16. >
  17.  
  18. The answer to this depends on the type of "Watchdog" you have, and the
  19. Fail-Stop/Fail-Operational characteristics of your system.  A technique
  20. that I have used is to design the watchdog hardware to allow a very small
  21. synchronized window for "kicking", and drive the watchdog off of a separate
  22. oscillator.  This will pick up subtle problems like large drifts in
  23. your clock rate, and will also detect bogus kicking of the watchdog.
  24. The software uses a high priority periodic interrupt to "kick" the watchdog,
  25. based on one or more "completion flags".  This provides great flexibility
  26. to program the proper safeguards in how the completion flags are set.
  27.  
  28.   Tom Griest
  29.  
  30.