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
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 :
> It has to do with the difficulty of providing a reliable
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
Hi,
very simple: A watchdog timer does not at all fit into the context of a
tickless-system. We want to sleep as long as possible, so waking up just
to please the WDT is very counter productive...
A WDT interface we could actually introduce, I guess just nobody did it
so far...
Cheers,
Hau
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
devel@riot-os.org
https://lists.riot-o