在"主程序餵狗論"中,最"強有的理論依據"就是---"程序跑飛了可是中斷不一定會死" （中斷一般都有自己固定不變的中斷向量地址,這樣即使主程序飛,中斷也能正確地跳入自己的軌道繼續運行.）
可如果只在主程序餵狗，由於中斷被無意關斷,那麼主程序實際就只幹傻餵狗功能,這種不工作也不死的。
所以建議：最好的辦法是主程序和中斷相結合的方法餵狗，這個需要根據實際程序中斷的特點編寫相應的餵狗功能（參考方法：在主循環內判中斷進入標誌(或中斷進入次數)再餵狗.）。
如果你沒什麼把握的話，還是建議只在主程序餵狗
而"中斷餵狗論"恰恰就是利用了這個"理論依據"!!!
中斷一般都有自己固定不變的中斷向量地址,這樣即使主程序飛,中斷也能正確地跳入自己的軌道繼續運行.
如果每個其他事件即程序模塊都設置一個"執行標誌",即執行過後都設置此標誌.
那麼,在定時(節拍)中斷中,可以從這些"執行標誌"掌握程序的運行狀況,達到檢控的目的.
若全部模塊正常運行,則清除全部標誌,否則,進行硬件復位(不餵狗)或軟件復位(在沒硬件看門狗時或需要立即復位時).
由於各模塊的運行週期不定,餵狗中斷可以靈活掌握.
"中斷餵狗論"和"主程序應答餵狗論"(不同於亂喂)效果基本相同,都能達到同樣的目的,但是它的餵狗週期不定,在低功耗的系統中,主循環的餵狗檢測較耗電.
而且主循環飛後只能期待硬件看門狗的復位了,故一般用在有硬件看門狗的系統中.而前者可用於有無硬件看門狗的系統中(當然要保證定時器及中斷不能被關閉,一般在主循環中刷新中斷配置較好).
當然,"中斷餵狗論"要耗損一些在中斷中的時間,但在定時(節拍)中斷中,是很短暫的,基本不影響系統的性能.
再駁"主程序餵狗論"
主程序活着比死了更難受!!!
所以沒有"雙向應答"機制的主程序強餵狗方式還是有漏洞的.
由於中斷被無意關斷,那麼主程序實際就只幹傻餵狗功能,這種不工作也不死的
程序要它何用???
所以我喜歡在主循環內刷新中斷標誌,即再次打開自己所需的全部中斷.
在主循環內判中斷進入標誌(或中斷進入次數)再餵狗.
或在主循環內設置主循環內駐留標誌(表示中斷是從主循環跳入的),再在中斷中
"主程序不飛可是中斷被關斷"將會如何???
一般是定時中斷(或OS的節拍中斷)中餵狗,因爲這種餵狗發生餵狗時間恆定,狗不得胃病.
中斷中餵狗後清除那個主循環內駐留標誌,這樣:
1.如果主程序飛,則定時中斷照常工作時,將收不到那個主循環內駐留標誌,則不餵狗(硬件看門狗),若無硬件看門狗,則定時中斷數次後,強行軟件復位!!!(起到了軟件看門狗的作用)
2.若主程序不飛,且主循環強制刷新中斷標誌,一般都能定時中斷,即使不能中斷,
則系統得不到餵狗,則硬件看門狗動作,系統復位.
從上2種情況分析,中斷餵狗的好處還能兼職軟件看門狗的作用!!!