[HN Gopher] Great Watchdog Timers For Embedded Systems (2016)
___________________________________________________________________
Great Watchdog Timers For Embedded Systems (2016)
Author : todsacerdoti
Score : 41 points
Date : 2025-01-31 23:00 UTC (9 hours ago)
(HTM) web link (www.ganssle.com)
(TXT) w3m dump (www.ganssle.com)
| petee wrote:
| > The 1750's built-in watchdog timer hardware was not used, over
| the objections of the lead software designer
|
| I wish they delved into this a little deeper; was it because the
| WDT disables with one op? That does seem quite risky on its own
| pjbk wrote:
| Unless this was not a Honeywell 1750 but a variant from another
| vendor (pretty common), the 1750 had only 2 hardware timers
| with just dedicated interrupts and no true watchdog
| functionality like a kicking key or handshake.
| sephamorr wrote:
| I've taken a number of MCUs through radiation testing including
| testing watchdogs. I've generally found that latchups often take
| out the watchdogs, even something like the STm32 independent
| watchdogs, and shouldn't be relied on. External hardware or a
| different system need to be deputized here.
| wildzzz wrote:
| Huge shout-out to the ISL706ARH for saving our butt through
| heavy ion testing.
| akoboldfrying wrote:
| >Toggle the WDT input too slowly, too fast, or not at all, and a
| timeout will occur.
|
| Reminds me of an article I read a few years ago about designing
| systems to detect when (human) train drivers fall asleep at the
| wheel. Apparently it was an arms race for a long time: Designers
| kept coming up with increasingly complicated tasks for drivers to
| complete to signal their conscious state, like tapping buttons
| with their hands or feet at various time intervals, while
| drivers, for their part, kept figuring out ways to perform those
| tasks while actually functionally unconscious...
| sho_hn wrote:
| And then trains adopted reCAPTCHA.
| vvanders wrote:
| WDT patterns are highly underrated, even in pure software there's
| value in degrading/recovering gracefully vs systems that have to
| be "perfect" 100% of the time and then force user intervention
| when they go wrong.
|
| One of my favorite blogs on the topic https://ferd.ca/the-zen-of-
| erlang.html that does a great job of covering how Erlang
| approached the topic, lots of learnings that can be applied more
| broadly.
| keeda wrote:
| His may not be a familiar name 'round these parts, but Jack
| Ganssle is a legend in the embedded systems industry. And he's
| very helpful to boot.
|
| Many lifetimes ago, as a freshly baked software engineer, I had a
| strong interest in Embedded Systems. Juggling interrupts,
| wrangling registers, counting clock cycles, banging bits, reading
| sensors, often in raw assembly so as to fit into limited flash
| memory was my idea of fun.
|
| So much so that I was contemplating doing a Master's degree in
| that area. However, I couldn't find a US University with a good
| program for that. I had seen Jack being very active on a few
| embedded-related forums, and on a lark, I emailed him for advice.
|
| And he responded! He gave me very sound advice, effectively
| explaining that graduate research in Embedded Systems is quite
| distinct from the actual low-level work that happens in the
| industry. This explained why I hadn't found any of the programs
| appealing. I took his advice gratefully and pursued a different
| area for my Master's, which shaped the rest of my career. Thanks
| again, Jack!
|
| I always intended to come back to Embedded Systems at some point,
| but unfortunately it never worked out. Partially because embedded
| engineers are criminally underpaid for the complexity of the work
| they do. As the article hints, writing software that runs
| reliably in arbitrarily harsh environments on low-cost, cheap,
| quirky hardware with extremely constrained resources is a
| different level of challenging.
___________________________________________________________________
(page generated 2025-02-01 08:01 UTC)