Watchdog Timer vs Thread.Sleep

Archive
#1

Which way is better?
The documents say thread: https://www.ghielectronics.com/docs/31/watchdog

            Watchdog.Enable(Watchdog.MAX_TIMEOUT);
            new ST.Thread(() =>
            {
                while (true)
                {
                    Watchdog.ResetCounter();
                    ST.Thread.Sleep((int)Watchdog.MAX_TIMEOUT - 1000);
                }
            }).Start();

or

            GT.Timer timer = new GT.Timer(30000);
            timer.Tick += (GT.Timer t) =>
                {
                    WatchDog.ResetCounter();
                };
#2

All timer events are executed in the same thread. This means that the next timer event is raised after the last one has finished.
Event that triggering the watchdog does not need to be very exact, and the call is quite short, it might lower the exactness of other timer events.

#3

I would have thought that the watchdog is there to ensure your app is still healthy, so I don’t see the point of the thread solution, on the other hand using the timer then you know that something hasn’t brought down the main scheduler, and if it does then the watchdog would fire

#4

Yes, and healthy means it still runs the code that resets the WD counter. I think thread solution works nicely in this case, unless I am missing something.

#5

have to agree to disagree, im afraid, but totally dependant on what you would want a watchdog to do, normally its another piece of logic/code that needs to reset it ie application layer vs driver layer

#6

maybe slightly off topic, but doesn’t micro framework have a ConstrainedExecution or something, I remember using it somewhere to trap something taking longer than expected, seemed useful at the time
@ Architect - I meant the application scheduler not the mf scheduler, but yeh both work if something catastrophic happens

#7

Watchdog is a hardware layer control. If your code is still running, and still “touching” the watchdog counter, the hardware WD won’t jump in. If something goes astray in your code (which could be as simple as blocked execution, or as bad as a unhandled exception halts all execution) then the WD counts down and is reset. It is really only the “I’ve failed, reset the hardware” error catch, and for a robust application you would still want other logic controls that handles the softer, “my app is still running but I don’t know what state I’m in” errors (although in a microcontroller sense, resetting may still be the most logical approach to recover that too)

#8

@ brett - I concur with your comments, ps 5-0 as I predicted :’(
pps thanks for the Emic boards I finally got them from OSHPark cheers