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,
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
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
Hi all,
unfortunately I cannot attend the NTSF meeting tomorrow :(
So I hacked some words on the current status and the future palns of the
FIB on a wiki page [1].
Best regards,
Martin
[1] https://github.com/RIOT-OS/RIOT/wiki/NSTF:-FIB-Status-and-future-plans
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 joakim.geb...@eistec.se:
It has to do with the difficulty
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
