Skip to main content
added 46 characters in body
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

What hardware? The ARM architecture in RPi has a watchdog timer resource. The point of a watchdog timer is for the system get unstuck and recover. I encourage you to use it (see the link below.) Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these OS releases know how to deal with a watchdog and respond in an intelligent way (and if they don't, choose a different one.)

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later and also place the system in a 'safe' state. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

What hardware? The ARM architecture in RPi has a watchdog timer resource. The point of a watchdog timer is for the system get unstuck and recover. I encourage you to use it (see the link below.) Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these OS releases know how to deal with a watchdog and respond in an intelligent way (and if they don't, choose a different one.)

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

What hardware? The ARM architecture in RPi has a watchdog timer resource. The point of a watchdog timer is for the system get unstuck and recover. I encourage you to use it (see the link below.) Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these OS releases know how to deal with a watchdog and respond in an intelligent way (and if they don't, choose a different one.)

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later and also place the system in a 'safe' state. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

added 98 characters in body
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

What hardware? The ARM architecture in RPi has a watchdog timer resource. The point of a watchdog timer is for the system get unstuck and recover. The ARM architecture in RPi has a watchdog resource, I encourage you to use it (see the link below.) Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these OS releases know how to deal with a watchdog and respond in an intelligent way (and if they don't, choose a different one.)

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

The point of a watchdog timer is for the system get unstuck and recover. The ARM architecture in RPi has a watchdog resource, I encourage you to use it. Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these know how to deal with a watchdog and respond in an intelligent way.

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

What hardware? The ARM architecture in RPi has a watchdog timer resource. The point of a watchdog timer is for the system get unstuck and recover. I encourage you to use it (see the link below.) Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these OS releases know how to deal with a watchdog and respond in an intelligent way (and if they don't, choose a different one.)

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

added 98 characters in body
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

The point of a watchdog timer is for the system get unstuck and recover. The ARM architecture in RPi has this as a watchdog resource, I encourage you to use it. Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these know how to deal with a watchdog and respond in an intelligent way.

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover, but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also log information for diagnostics later, more importantly, log information for diagnostics later. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

XY problem. This needs to be dealt with by software. (Obi-wan voice: “Use the source, Luke…”)

The point of a watchdog timer is for the system get unstuck and recover. The ARM architecture in RPi has this as a resource, I encourage you to use it. Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these know how to deal with a watchdog in an intelligent way.

If you don’t want the system to recover, but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also log information for diagnostics later. Again, this would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

XY problem. This isn't a job for a 555. This needs to be dealt with by software, with a little help from RPi hardware. (Obi-wan voice: “Use the source, Luke…”)

The point of a watchdog timer is for the system get unstuck and recover. The ARM architecture in RPi has a watchdog resource, I encourage you to use it. Further, RPi is powerful enough to run a robust RTOS, be it an open-source or commercial package. Any of these know how to deal with a watchdog and respond in an intelligent way.

Related: https://diode.io/raspberry%20pi/running-forever-with-the-raspberry-pi-hardware-watchdog-20202/

What does that mean, 'respond in an intelligent way'? If you don’t want the system to recover but simply stop and inform the user that it has done so (why?), the watchdog timeout can instead cause a branch to a routine that flashes an LED and just sits there until the user intervenes. This routine can also, more importantly, log information for diagnostics later. Again, this ability to respond to the watchdog and log errors would be something your OS would have built in.

Relevant: https://stackoverflow.com/questions/13217959/how-to-use-the-watchdog-timer-in-a-rtos

For some inspiration, this is how the Apollo Guidance Computer team did it: https://youtu.be/B1J2RMorJXM

added 98 characters in body
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166
Loading
added 16 characters in body
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166
Loading
added 16 characters in body
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166
Loading
added 108 characters in body
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166
Loading
Source Link
hacktastical
  • 58.6k
  • 2
  • 54
  • 166
Loading