Add an external watchdog module

[Quency-D]

1. It has already been tested on heltec-mesh-solar and heltec-v4.
2. The newly added watchdog module does not conflict with the existing meshsolar.

[0x156]

Found this from here: http://community.heltec.cn/t/heltec-meshtower-resets-its-configuration-itself/20570/36?u=brikots
I have flashed it to my Heltec mesh solar/tower, and I can confirm it works properly: it does not reboot every 9 minutes.

[weebl2000]

A few suggestions — the main one is a units mismatch (ms vs seconds) in the repeater sleep guard.

[Quency-D]

@weebl2000 Thank you for your suggestions. All have been revised.

[liamcottle]

Please refactor all instances of ex to external, so the language is more explicit.

E.g:

• HAS_EX_WATCHDOG -> HAS_EXTERNAL_WATCHDOG
• EX_WATCHDOG_DONE_PIN -> EXTERNAL_WATCHDOG_DONE_PIN
• EX_WATCHDOG_WAKE_PIN -> EXTERNAL_WATCHDOG_WAKE_PIN
• EX_WATCHDOG_TIMEOUT_MS -> EXTERNAL_WATCHDOG_TIMEOUT_MS
• ExWatchdogManager -> ExternalWatchdogManager
• SolarExWatchdog -> SolarExternalWatchdog
• ex_watchdog -> external_watchdog

[weebl2000]

@Quency-D addressed the review comments and opened a PR to your branch Quency-D#4

[weebl2000]

@liamcottle addressed the comments, variables are clearly named now!

[Quency-D]

@Quency-D addressed the review comments and opened a PR to your branch Quency-D#4

Thank you for your contribution; the connection has been merged.

[IoTThinks]

ESP32 has various watchdogs.
May I know the context or usecases why we need this extra watchdog?

[Quency-D]

ESP32 has various watchdogs. May I know the context or usecases why we need this extra watchdog?

An external watchdog is more reliable than an internal one. It operates independently, providing an extra layer of protection.

[ripplebiz]

Just wondering about doing the 2's complement trick here? So that the 49-day glitch doesn't happen.

[Quency-D]

This is indeed a problem; let me think of a good solution.

[ripplebiz]

Just see Dispatcher::millisHasNowPassed() for reference. Usually, you just keep a last (ie in the past) timestamp, and compare to millis() for some duration value. Rather than holding a future timestamp

[IoTThinks]

@Quency-D What are the real usecases or problems this watchdog is trying to address / fix?

[Quency-D]

@Quency-D What are the real usecases or problems this watchdog is trying to address / fix?

Outdoor solar energy equipment can guarantee continuous normal operation.

[ripplebiz]

If I'm reading this right, this is the remaining time left until next feed() ?
Or should this be whatever the fixed interval is?

[Quency-D]

This is the time remaining until the next feed(), not a fixed time interval.

[ripplebiz]

Just see Dispatcher::millisHasNowPassed() for reference. Usually, you just keep a last (ie in the past) timestamp, and compare to millis() for some duration value. Rather than holding a future timestamp

[ripplebiz]

I don't know the specifics of the Mesh Solar's watchdog timer, but does it just have a default timeout of some known value? And is the EXTERNAL_WATCHDOG_TIMEOUT_MS some safe interval INSIDE this default timeout interval? (ie. you don't want to two to be exactly the same, as there will be slight delays until feed() will be called)

[Quency-D]

The hardware is configured to run for about 10 minutes, while the code is configured for 8 minutes, leaving a 2-minute margin, which should be more than enough.

[Quency-D]

Just see Dispatcher::millisHasNowPassed() for reference. Usually, you just keep a last (ie in the past) timestamp, and compare to millis() for some duration value. Rather than holding a future timestamp

Hi @ripplebiz, I made some changes. I'm now using the last feeding time as the criterion instead of a future time. I'm not sure if my understanding is correct.