Why is it generally not recommended to feed dogs during breaks?

In the "Main Program Feeding Dog Theory", the most "strong theoretical basis" is --- "The program may run away, but the interrupt may not necessarily die" (interrupts generally have their own fixed interrupt vector addresses, so that even if the main program runs away, the interrupt can correctly jump into its own track and continue to run.)

 

But if you only feed the dog in the main program, because the interrupt is accidentally turned off, the main program actually only does the stupid dog feeding function, which does not work but also does not die.

 

So it is recommended that the best way is to feed the dog by combining the main program and interrupts. This requires writing a corresponding dog feeding function based on the characteristics of the actual program interrupt (reference method: judge the interrupt entry flag (or the number of interrupt entries) in the main loop and then feed the dog).

 

If you are not sure, it is recommended to feed the watchdog only in the main program.



The "interrupt watchdog feeding theory" just uses this "theoretical basis"!!!

Interrupts generally have their own fixed interrupt vector address, so that even if the main program is flying, the interrupt can correctly jump into its own track and continue to run.

If each other event, that is, the program module, sets an "execution flag", that is, this flag is set after execution.

Then, in the timing (beat) interrupt, the running status of the program can be grasped from these "execution flags" to achieve the purpose of prosecution.

If all modules are running normally, all flags are cleared, otherwise, hardware reset (no watchdog feeding) or software reset (when there is no hardware watchdog or immediate reset is required).

Since the running cycle of each module is uncertain, the dog feeding interrupt can be flexibly controlled.

The effects of "interrupt feeding theory" and "main program response feeding theory" (different from random feeding) are basically the same, and both can achieve the same purpose, but its feeding cycle is uncertain. In a low-power system, the main loop feeding detection consumes more power.
And after the main loop flies, you can only expect the hardware watchdog to reset, so it is generally used in systems with hardware watchdogs. The former can be used in systems with or without hardware watchdogs (of course, it is necessary to ensure that the timer and interrupt cannot be turned off, and it is generally better to refresh the interrupt configuration in the main loop).

Of course, the "interrupt feeding theory" consumes some time in the interrupt, but in the timing (beat) interrupt, it is very short and basically does not affect the performance of the system.

 

Refuting the "main program feeding the dog theory"
The main program is more uncomfortable to be alive than dead!!!

Therefore, the main program forced feeding the dog method without the "two-way response" mechanism is still flawed.

Since the interrupt is turned off unintentionally, the main program actually only does the dog feeding function.

What is the use of this program that does not work and does not die???

So I like to refresh the interrupt flag in the main loop, that is, turn on all the interrupts I need again.

In the main loop, judge the interrupt entry flag (or the number of interrupt entries) and then feed the dog.

Or set the main loop resident flag in the main loop (indicates that the interrupt jumps in from the main loop), and then in the interrupt,

"the main program does not fly but the interrupt is turned off", what will happen???

Generally, the dog is fed in the timer interrupt (or the OS beat interrupt), because this kind of dog feeding occurs at a constant feeding time, and the dog will not get stomach problems.

After feeding the dog in the interrupt, clear the main loop resident flag, so:

1. If the main program is flying, when the timed interrupt works normally, it will not receive the resident flag in the main loop, and the dog will not be fed (hardware watchdog). If there is no hardware watchdog, the timed interrupt will be forced to reset the software after several times!!! (It plays the role of software watchdog)

2. If the main program is not flying, and the main loop is forced to refresh the interrupt flag, it can generally be interrupted on time. Even if it cannot be interrupted,

the system cannot be fed, and the hardware watchdog will be activated and the system will be reset.

From the above two situations, the benefit of interrupt feeding can also serve as a part-time software watchdog!!!