單片機編程:如何餵狗的靈魂拷問...

[導讀] 單片機程序寫辣麼多，看門狗狗天天見，你的狗狗養的對麼？不停的餵狗，只要狗不叫就完了嘛？真是這樣麼？事實上可能不是你想的辣麼簡單

啥叫看門狗？

看門狗也稱為看門狗定時器，本質上是一種定時電路或者軟體定時器機制。

工作原理：

看門狗的硬體基礎是一個計數器，該計數器被設置為某個定時初值，然後遞減至零。軟體負責經常將計數重置為其定時初值，以確保計數永遠不會達到零。如果確實達到零，則意味著某種故障發生，該採取對應措施應對，或重啟或進入失效安全狀態，具體取決於系統的設計。

正常工作時，單片機、處理器或者線程，周期性重置看門狗定時器的定時值，定時器則在後臺不斷的計數，如果定時時間到了且沒有再次餵狗，則狗叫，意味著一些不尋常的事情發生了！此時，狗狗對外發出指令，執行相應的動作。這裡所謂的動作究竟是什麼？取決於實際系統的設計。常見的看門狗晶片則會發出復位信號給單片機或者處理，對於軟體定時器而言，具體會有何種動作，則靈活多變，具體取決於採用何種安全策略。

通俗講也稱為餵狗，這個定時值相當於狗糧，狗狗吃飽了，胃裡不斷消耗狗糧，如果在消耗完之前沒有在餵狗糧，再狗狗餓得直叫喚，發出預警消息。反言之，一個一直正常工作的系統，其看門狗總是被餵養的很好，不會餓了狂叫。

註：看到有文章把重置看門狗定時器叫踢狗(kick watchdog)，嗯嗯，這不太好，要對狗狗好一點，不要踢，叫餵吧～～～

看門狗機制在電子系統中作用非常之重要，這裡舉個極端的慄子，火星車如果程序掛了，就相當於失聯，如果沒有看門狗電路。你想像一下是什麼場景，無法通訊無法喚醒，秒變太空垃圾～～～

能看住哪些錯誤呢？
強電磁幹擾破壞數據導致系統異常，這你或許不好理解，你就想像一下軍事領域，或者航空航天領域很多電子系統，常工作在強電磁幹擾環境中

原因萬萬千，憋慌！你還有個好狗狗在幫你，讓看門狗來收拾殘局吧。在一個複雜的嵌入式系統中，不可能保證沒有bug，但是通過使用看門狗，您可以保證沒有任何bug會無限期地掛起系統。

狗叫後該咋整？

常見的處理策略有哪些呢？

系統復位，大多數人都有的體驗，系統掛了咋整，重啟。不由想起了劉歡的<<從頭再來>>，人生如能重啟該多好，然而並不能！有興趣的聽聽～～～失效安全，老外常叫fail-safe 模式。就是設備即使出現致命故障了，也別造成安全事故。粗魯點說，就是掛了，也不要影響他人。不易理解，舉個例子，一個正在下降的電梯，加入看門狗檢測到程序異常了，安全的做法是趕緊停止電機轉動，否則自由落體，就要涼涼啦。這在IEC61508 功能安全標準，或者醫療安全標準、汽車安全標準中都有體現。這裡描述一種推薦做法，晶片復位後，利用晶片復位狀態寄存器值，對看門狗復位事件計數，事不過三，如果連續三次此類復位，則保守做法就是將系統切換到安全狀態或顯示錯誤消息，這樣可以避免無限重新啟動。怎麼做呢？以IAR為例，可以定義一個變量不讓系統自動初始化（如IAR中叫,__no_init)，實現計數，復位後其值仍然保存，除非斷電。__no_init int wdtResetCounter;

如果我們希望系統快速恢復，應該採用看門狗復位後的初始化比正常加電初始化短的策略。也就是說跳過設備的一些自檢。當然，在某些系統中最好進行全面自檢，因為看門狗超時的根本原因可能是通過此類硬體異常導致的。

具體咋餵狗呢？

對於裸機程序而言，我推薦了下面兩種處理策略：故障檢測式餵狗，故障檢測加強式餵狗。

故障檢測式餵狗

對於一個裸奔單片機程序而言，可以在餵狗時同時檢測一些關鍵的運行時狀態，比如棧深度、緩衝區、關鍵功能鏈的硬體（如傳感器、執行機構等）,如這些狀態異常，則記錄錯誤狀態，將設備至於功能安全狀態。

故障檢測加強式餵狗

啥叫序列檢測式餵狗呢？IEC-61508中有種範式叫sequence check,有點邪乎？看下圖，你就馬上明了了。

將是將main函數的主體關鍵功能塊，設置一個序列標記，如果如果序列出錯就做安全故障處理，正確則繼續下一塊的執行。在餵狗的時候，看下序列是否正確，正確就喂，否則就做錯誤處理，或者乾脆讓狗叫也是一種方式。

對於多任務實時系統而言，有這樣一些不一樣的需求：

檢測由於高優先級任務佔用CPU而導致某些低優先級任務無法運行母狗帶群仔餵狗法

取這個名字有點俗了，哈哈哈。為了方便理解，就這麼叫吧，依然上個圖了再解釋吧：

實現策略描述：

watchdogTask可看成狗窩，裡面住了一群狗，其中硬體看門狗是母狗，子任務軟體看門狗為小狗仔。每個子任務需要在每一個loop循環餵一次狗（當然實際實現時也可以加入任務故障檢測式餵狗），在watchdogTask每一個循環都對所有軟體看門狗遞減，如果溢出則軟狗叫了，需要做異常處理（復位或進入失效安全模式）。如果所有的軟體狗都沒有溢出，則餵硬體看門狗（可能是單片機內置或外置晶片）

實際實現時須注意：

每個loop應調用os_delay一定時間，以出讓CPU時間給其他task運行。掛起的時間應小於最大硬體看門狗延時時間。狗多久叫合理呢? 過短之痛

看門狗定時器定時時間設置過短，則系統容易誤判，可能會導致頻繁複位或進入失效安全模式。因為任何一條安全鏈的好壞取決於它最薄弱的一環，如果選擇一個太短的超時間隔。固件的循環時間是動態的，尤其外部的異步事件比較多，或者有中斷嵌套的情況，則波動會比較大，所以需要考慮最壞情況，系統循環一次要多久。

過長之害

一種方法是選擇一個幾秒鐘長的間隔。當您僅嘗試復位一個確實掛起的系統，但不希望對系統的時間進行詳細研究時，可以採用此策略。這是一個健壯的方法。但有些系統需要快速恢復，這就造成故障診斷過慢的危害了，尤其在一些對安全要求極高的場合，比如核電系統，汽車電子系統、醫療器械繫統等等。

所以實際設計時需要兼顧最壞情況下，儘量選擇相對較短的定時時長，在兩者中尋找一個平衡。

總結一下

對於單片機編程而言，其實對嵌入式Linux甚至在資料庫中，看門狗策略都有大量的應用，如何合理的使用看門狗，對於設計一個健壯的電子系統而言是非常重要的一個話題。

原創不易，如覺得本文對有價值，請點再看或者分享給身邊的小夥伴，讓人更多看到。