An idea: Create a multi-channel software watchdog that in turn pokes the hardware watchdog when all parameters are met. We could configure different timeouts for different channels and each critical process can have its own channel(s) which they update independently.
Some risks of this approach is that it will be possible for software errors to make the software watchdog misbehave and poke the hardware watchdog and keep the system running when it should be reset. Best regards, Joakim Thanks for your explanations. I understand why it is counter productive. But how RIOT will make sure that the board is not stuck in a deadlock? This is mandatory for industrial context. Cheers, 2015-04-29 15:07 GMT+02:00 Joakim Gebart <[email protected]>: > It has to do with the difficulty of providing a reliable way of poking the > watchdog in an event driven, tickless, system such as RIOT. Maybe it is > time to start discussing a watchdog api? > In order to get any traction within industry applications I believe it > will be necessary to at least provide an api for applications to use the > watchdog. > > Best regards, > Joakim Gebart > Eistec AB > www.eistec.se > On Apr 29, 2015 2:43 PM, "Baptiste Clenet" <[email protected]> wrote: > >> Hi, >> >> I've got two questions concerning WDT: >> - Why do we disable it on the samr21 at launch time? >> - Why doesn't RIOT provide a wdt.h in drivers/include/periph? >> >> Cheers, >> >> -- >> >> *Clenet Baptiste* >> >> >> _______________________________________________ >> devel mailing list >> [email protected] >> https://lists.riot-os.org/mailman/listinfo/devel >> >> > _______________________________________________ > devel mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel > > -- *Clenet Baptiste* _______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
