為何一般不建議在中斷中喂狗？

可如果只在主程序喂狗，由于中斷被無意關斷,那么主程序實際就只干傻喂狗功能,這種不工作也不死的。

所以建議：最好的辦法是主程序和中斷相結合的方法喂狗，這個需要根據實際程序中斷的特點編寫相應的喂狗功能（參考方法：在主循環內判中斷進入標志(或中斷進入次數)再喂狗.）。

如果你沒什么把握的話，還是建議只在主程序喂狗



而"中斷喂狗論"恰恰就是利用了這個"理論依據"!!!

中斷一般都有自己固定不變的中斷向量地址,這樣即使主程序飛,中斷也能正確地跳入自己的軌道繼續運行.

如果每個其他事件即程序模塊都設置一個"執行標志",即執行過后都設置此標志.

那么,在定時(節拍)中斷中,可以從這些"執行標志"掌握程序的運行狀況,達到檢控的目的.

若全部模塊正常運行,則清除全部標志,否則,進行硬件復位(不喂狗)或軟件復位(在沒硬件看門狗時或需要立即復位時).

由于各模塊的運行周期不定,喂狗中斷可以靈活掌握.

"中斷喂狗論"和"主程序應答喂狗論"(不同于亂喂)效果基本相同,都能達到同樣的目的,但是它的喂狗周期不定,在低功耗的系統中,主循環的喂狗檢測較耗電.
而且主循環飛后只能期待硬件看門狗的復位了,故一般用在有硬件看門狗的系統中.而前者可用于有無硬件看門狗的系統中(當然要保證定時器及中斷不能被關閉,一般在主循環中刷新中斷配置較好).

當然,"中斷喂狗論"要耗損一些在中斷中的時間,但在定時(節拍)中斷中,是很短暫的,基本不影響系統的性能.

再駁"主程序喂狗論"
主程序活著比死了更難受!!!

所以沒有"雙向應答"機制的主程序強喂狗方式還是有漏洞的.

由于中斷被無意關斷,那么主程序實際就只干傻喂狗功能,這種不工作也不死的

程序要它何用???

所以我喜歡在主循環內刷新中斷標志,即再次打開自己所需的全部中斷.

在主循環內判中斷進入標志(或中斷進入次數)再喂狗.

或在主循環內設置主循環內駐留標志(表示中斷是從主循環跳入的),再在中斷中

"主程序不飛可是中斷被關斷"將會如何???

一般是定時中斷(或OS的節拍中斷)中喂狗,因為這種喂狗發生喂狗時間恒定,狗不得胃病.

中斷中喂狗后清除那個主循環內駐留標志,這樣:

1.如果主程序飛,則定時中斷照常工作時,將收不到那個主循環內駐留標志,則不喂狗(硬件看門狗),若無硬件看門狗,則定時中斷數次后,強行軟件復位!!!(起到了軟件看門狗的作用)

2.若主程序不飛,且主循環強制刷新中斷標志,一般都能定時中斷,即使不能中斷,

則系統得不到喂狗,則硬件看門狗動作,系統復位.

從上2種情況分析,中斷喂狗的好處還能兼職軟件看門狗的作用!!!