Timeline for Blink when input is constant?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 2, 2021 at 23:46 | comment | added | ThreePhaseEel | @jonk -- the issue with external WDTs is that they are relatively hard to make safe against accidental feeding compared to an internal WDT -- it's possible by devoting say an entire I/O port to feeding the watchdog, or if you have an external memory bus, but it'll require a bit of logic to do so | |
| Oct 2, 2021 at 20:01 | comment | added | jonk | @hacktastical No. Read the linked article I gave earlier, if you need to see actual, exact and detailed reasons why an internal WDT isn't safe. The author is credible and writes well about the topic. If you aren't seeing the reasons now, you will after reading it. Just give it a shot. | |
| Oct 2, 2021 at 19:47 | comment | added | Bergi | @hacktastical It sounds like OP doesn't look for an exception interrupt to be handled by the software itself. They want a human exception handler, notified by a blinking LED, where the human in the loop knows how to reset the software in any imaginable failure state :-) | |
| Oct 2, 2021 at 19:28 | comment | added | hacktastical | As it is, to use an external watchdog timer you have to configure a non-maskable interrupt pin. That’s pretty much the same issue as using the internal watchdog: if the configuration is wrong, even if the watchdog times out it won’t cause the exception to fire. | |
| Oct 2, 2021 at 19:25 | comment | added | hacktastical | I haven’t used an external watchdog chip in years. The programmers I’ve worked with seem pretty comfortable with using an on chip resource, so I haven’t bothered with it (one of those programmers is a well-known kernel guy.) Of course it’s not gonna catch a dead oscillator or other catastrophic hardware problem, but for workaday software errors like memory leaks, pointer smashes and other typical things that can cause the system to die the internal WDT works fine. | |
| Oct 2, 2021 at 15:10 | comment | added | 2e0byo | Failing OS watchdog is not so very remote: I have one system running (controlling the fridge) on an esp32 where, as far as I can tell, the internal oscillator simply stops running under some (probably EMI related) conditions. An external watchdog---actually built around a 555 with reset pulse---keeps the hardware alive. But a dedicated hardware watchdog chip would be a much better idea. Be aware of the danger of the watched hardware getting stuck in 'resetting' mode. (In my case I have a series capacitor to prevent tying the watchdog down). | |
| Oct 2, 2021 at 9:43 | comment | added | jonk | @DragoRosson Read this article. It should also add some fuel to the fire: "... no WDT internal to the CPU is really safe." And I agree. I've never used an internal WDT for WDT purposes. I use them, on occasion for timers. But not for WDTs. Where it matters, there is always an external WDT. Learned that lesson so long ago I can't exactly recall the decade anymore. ;) | |
| Oct 2, 2021 at 9:28 | comment | added | Drago Rosson | So like @jonk is saying, something completely external to the pi is preferred (or I'd at least like to know what the best external option would be) because it'd be isolated and unlikely to be affected by software changes. | |
| Oct 2, 2021 at 9:23 | comment | added | Drago Rosson | I like this answer for others that may come by this question and the software-configured watchdog really is right for them. In my situation, I want it to be foolproof, and I am that fool who might misconfigure something, or screw up my startup scripts. The application being watched is a work in progress, which is also why I want the blinking status LED. I want to know problems when they happen so I can fix them. I know I'll be around it to investigate and reset it myself. | |
| Oct 2, 2021 at 5:37 | comment | added | jonk | The quality of the utility of the LED as described by the OP is entirely dependent on the thought and care that goes into using it. I also wrote to my comment to Spehro that the LED's use may be the subject of future modification and that an external SOT23-6 MCU is the right approach. It is, almost by definition, not short-sighted. Quite the opposite, in fact, since an external MCU can be modified per future requirements, as well. It's the right way to go. | |
| Oct 2, 2021 at 5:07 | comment | added | hacktastical | I just think it’s kind of short-sighted to have an ‘I’m alive’ blink as a solution. | |
| Oct 2, 2021 at 5:05 | comment | added | hacktastical | Yes, whatever handles the watchdog has to be trusted code. That’s kind of the point. Not knowing the whole system that OP is proposing I can’t make any statements about that. If they’re writing something that requires functional safety then they are obliged to use code developed under an applicable framework (like ISO26262 for example.) | |
| Oct 2, 2021 at 4:45 | comment | added | jonk | An RTOS may be perfectly able to tell if it is working correctly. It will not know when your own code is or isn't. I never depend on an O/S I didn't write myself to "know how to deal with a watchdog and respond in an intelligent way" with respect to an application I'm writing. And because of that, I would not permit an O/S I didn't write to operate the watchdog. (And yes, I've been writing O/S systems from the ground up from before I worked on the Unix v6 kernel code in 1978. A very long time.) | |
| Oct 1, 2021 at 21:51 | history | edited | hacktastical | CC BY-SA 4.0 |
added 46 characters in body
|
| Oct 1, 2021 at 21:41 | history | edited | hacktastical | CC BY-SA 4.0 |
added 98 characters in body
|
| Oct 1, 2021 at 21:34 | history | edited | hacktastical | CC BY-SA 4.0 |
added 98 characters in body
|
| Oct 1, 2021 at 21:27 | history | edited | hacktastical | CC BY-SA 4.0 |
added 98 characters in body
|
| Oct 1, 2021 at 21:08 | history | edited | hacktastical | CC BY-SA 4.0 |
added 16 characters in body
|
| Oct 1, 2021 at 20:53 | history | edited | hacktastical | CC BY-SA 4.0 |
added 16 characters in body
|
| Oct 1, 2021 at 20:47 | history | edited | hacktastical | CC BY-SA 4.0 |
added 108 characters in body
|
| Oct 1, 2021 at 20:38 | history | answered | hacktastical | CC BY-SA 4.0 |