为何一般不建议在中断中喂狗？

在"主程序喂狗论"中,最"强有的理论依据"就是---"程序跑飞了可是中断不一定会死" （中断一般都有自己固定不变的中断向量地址,这样即使主程序飞,中断也能正确地跳入自己的轨道继续运行.）

 

可如果只在主程序喂狗，由于中断被无意关断,那么主程序实际就只干傻喂狗功能,这种不工作也不死的。

 

所以建议：最好的办法是主程序和中断相结合的方法喂狗，这个需要根据实际程序中断的特点编写相应的喂狗功能（参考方法：在主循环内判中断进入标志(或中断进入次数)再喂狗.）。

 

如果你没什么把握的话，还是建议只在主程序喂狗



而"中断喂狗论"恰恰就是利用了这个"理论依据"!!!

中断一般都有自己固定不变的中断向量地址,这样即使主程序飞,中断也能正确地跳入自己的轨道继续运行.

如果每个其他事件即程序模块都设置一个"执行标志",即执行过后都设置此标志.

那么,在定时(节拍)中断中,可以从这些"执行标志"掌握程序的运行状况,达到检控的目的.

若全部模块正常运行,则清除全部标志,否则,进行硬件复位(不喂狗)或软件复位(在没硬件看门狗时或需要立即复位时).

由于各模块的运行周期不定,喂狗中断可以灵活掌握.

"中断喂狗论"和"主程序应答喂狗论"(不同于乱喂)效果基本相同,都能达到同样的目的,但是它的喂狗周期不定,在低功耗的系统中,主循环的喂狗检测较耗电.
而且主循环飞后只能期待硬件看门狗的复位了,故一般用在有硬件看门狗的系统中.而前者可用于有无硬件看门狗的系统中(当然要保证定时器及中断不能被关闭,一般在主循环中刷新中断配置较好).

当然,"中断喂狗论"要耗损一些在中断中的时间,但在定时(节拍)中断中,是很短暂的,基本不影响系统的性能.

 

再驳"主程序喂狗论"
主程序活着比死了更难受!!!

所以没有"双向应答"机制的主程序强喂狗方式还是有漏洞的.

由于中断被无意关断,那么主程序实际就只干傻喂狗功能,这种不工作也不死的

程序要它何用???

所以我喜欢在主循环内刷新中断标志,即再次打开自己所需的全部中断.

在主循环内判中断进入标志(或中断进入次数)再喂狗.

或在主循环内设置主循环内驻留标志(表示中断是从主循环跳入的),再在中断中

"主程序不飞可是中断被关断"将会如何???

一般是定时中断(或OS的节拍中断)中喂狗,因为这种喂狗发生喂狗时间恒定,狗不得胃病.

中断中喂狗后清除那个主循环内驻留标志,这样:

1.如果主程序飞,则定时中断照常工作时,将收不到那个主循环内驻留标志,则不喂狗(硬件看门狗),若无硬件看门狗,则定时中断数次后,强行软件复位!!!(起到了软件看门狗的作用)

2.若主程序不飞,且主循环强制刷新中断标志,一般都能定时中断,即使不能中断,

则系统得不到喂狗,则硬件看门狗动作,系统复位.

从上2种情况分析,中断喂狗的好处还能兼职软件看门狗的作用!!!