Closed frederikvs closed 3 years ago
Thanks for the addition, a 200ms WD is a lot better than none should the SW hang and miss an over current event. Adding a make file option like we have with wifi etc. would be preferable.
@kanflo makefile option for the watchdog. Default is ON for now, if you prefer OFF I'll change it.
I've tested it both ways on my hardware. (I've also tested with a decreased timeout so it triggers on a switch to the funcgen screen, and used that to verify that it's active with the makefile option set ON, and not active if it's OFF.)
It works fine on my ancient '5005.
I've implemented a basic watchdog timer, because I'm currently working on a project where I'd like the additional safety. See also issue #145 .
Since pretty much everything happens in the event_handler loop, I figured kicking the watchdog from there should work : so long as we can keep processing events, we're good.
However, with this simple approach we need to set the watchdog quite high. Switching to the function generator screen takes 110ms. I've set it to 200ms for now, since I'm not sure what the longest operations would be. Most other events seem to take only a few ms. Switching from CL to CC screen or similar takes less than 30ms.
If the system would hang, and we ignore an OCP or OVP for 200ms, how problematic is that? Do we need a more sophisticated watchdog, or will this be OK?
If we're going to go with this simple solution, a few more measurements of long-duration events would be welcome. I've included some instrumentation code, under ifdefs. I didn't want to clutter up the makefile, so you should just add the #define at the top of the file. (If you prefer I could put it in the makefile as well, just let me know.) For getting the value of max_wdog_interval I just run it with gdb attached, and from time to time halt it and print the value. It could of course be modified that it (periodically?) dbg_prints the value.