Hi Will, > On Aug 29, 2016, at 4:53 PM, will sanfilippo <[email protected]> wrote: > > I have some questions: > > 1) What happens if the internal watchdog does not allow for a long timeout?
I was thinking of just returning an error from init in that case, but maybe we need a routine that returns the max supported timeout. And make at least the watchdogs for the current MCUs support at least 30 seconds? > 2) When developers create the system and want a HW watchdog, what in the OS > tickles the watchdog? Is that done by the sanity task or is it done by the OS > in some other manner (os time tick, for example)? Or does the creator of the > application need to provide for the tickle? This would be done by sanity task. For folks who do not want to use sanity task would have to come up with another mechanism. > Thanks > > PS I am not sure if memory serves (and it rarely does!) but I think I have > worked on older MCU’s whose maximum internal watchdog timeout was < 1 second. > I dont know if current day MCU’s have this kind of limitation, but if they > did, how would that be addressed? Or is it not a concern… Argh, I had not considered such hardware. I think I would make the tickling happen then on 2 layers; sub second stuff being internal to driver through a timer interrupt, and the slower tickling happening through the watchdog API. >> On Aug 29, 2016, at 4:40 PM, marko kiiskila <[email protected]> wrote: >> >> Hi, >> >> I was going to add support for hardware watchdog(s). >> The API I was thinking would be pretty simple. >> >> The first user for this would be the sanity task. >> >> —8<--- >> /* >> * Set the watchdog time to fire no sooner than 'expire_secs' seconds from >> now. >> */ >> int hal_watchdog_init(int expire_secs); >> >> /* >> * Tickles the watchdog. Needs to be done before 'expire_secs' fires. >> */ >> int hal_watchdog_tickle(void); >> >> /* >> * Stops the watchdog. >> */ >> int hal_watchdog_stop(void); >> >> —8<——— >> >> Let me know if this doesn’t seem right. >
