在”主程序喂狗论”中,最”强有的理论依据”便是—“程序跑飞了但是中止纷歧定会死” （中止一般都有自己固定不变的中止向量地址,这样即便主程序飞,中止也能正确地跳入自己的轨迹持续运转.）
可假如只在主程序喂狗，由于中止被无意关断,那么主程序实践就只干傻喂狗功用,这种不作业也不死的。
所以主张：最好的办法是主程序和中止相结合的办法喂狗，这个需求依据实践程序中止的特色编写相应的喂狗功用（参阅办法：在主循环内判中止进入标志(或中止进入次数)再喂狗.）。
假如你没什么把握的话，仍是主张只在主程序喂狗
而”中止喂狗论”恰恰便是利用了这个”理论依据”!!!
中止一般都有自己固定不变的中止向量地址,这样即便主程序飞,中止也能正确地跳入自己的轨迹持续运转.
假如每个其他事情即程序模块都设置一个”履行标志”,即履行往后都设置此标志.
那么,在守时(节拍)中止中,能够从这些”履行标志”把握程序的运转状况,到达检控的意图.
若悉数模块正常运转,则铲除悉数标志,不然,进行硬件复位(不喂狗)或软件复位(在没硬件看门狗时或需求当即复位时).
由于各模块的运转周期不定,喂狗中止能够灵敏把握.
“中止喂狗论”和”主程序应对喂狗论”(不同于乱喂)效果根本相同,都能到达相同的意图,但是它的喂狗周期不定,在低功耗的体系中,主循环的喂狗检测较耗电.
并且主循环飞后只能等待硬件看门狗的复位了,故一般用在有硬件看门狗的体系中.而前者可用于有无硬件看门狗的体系中(当然要确保守时器及中止不能被封闭,一般在主循环中改写中止装备较好).
当然,”中止喂狗论”要耗费一些在中止中的时刻,但在守时(节拍)中止中,是很时刻短的,根本不影响体系的功用.
再驳”主程序喂狗论”
主程序活着比死了更难过!!!
所以没有”双向应对”机制的主程序强喂狗方法仍是有缝隙的.
由于中止被无意关断,那么主程序实践就只干傻喂狗功用,这种不作业也不死的
程序要它何用???
所以我喜爱在主循环内改写中止标志,即再次翻开自己所需的悉数中止.
在主循环内判中止进入标志(或中止进入次数)再喂狗.
或在主循环内设置主循环内驻留标志(表明中止是从主循环跳入的),再在中止中
“主程序不飞但是中止被关断”将会怎么???
一般是守时中止(或OS的节拍中止)中喂狗,由于这种喂狗产生喂狗时刻稳定,狗不得胃病.
中止中喂狗后铲除那个主循环内驻留标志,这样:
1.假如主程序飞,则守时中止照旧作业时,将收不到那个主循环内驻留标志,则不喂狗(硬件看门狗),若无硬件看门狗,则守时中止数次后,强行软件复位!!!(起到了软件看门狗的效果)
2.若主程序不飞,且主循环强制改写中止标志,一般都能守时中止,即便不能中止,
则体系得不到喂狗,则硬件看门狗动作,体系复位.
从上2种状况剖析,中止喂狗的优点还能兼职软件看门狗的效果!!!
