前言

一個學員在學習 uCOS 系統過程中，對看門狗任務的優先級產生了疑惑，到底該把喂狗任務優先級設置成最高還是最低好？

這里談談魚鷹個人看法，首先給出結論，最低，甚至是在空閑任務運行（使用鉤子函數）。

理由

首先我們要知道看門狗的工作是什么？為什么要設置看門狗。

很多產品出廠時，都會開啟看門狗，這是產品運行的最后保障，可以在出現軟件 bug 時（如hardfault，死循環等），及時恢復運行，讓產品可以重新繼續工作下去，但這不意味著萬事大吉，一旦發現了看門狗引起的復位問題（可以通過寄存器標志位查看因何復位），一定要找到問題根因，否則出現了一次，后面一定還會不停出現，用戶體驗相當不好。

那么我們應該怎么設置看門狗的功能呢？這個學員準備這么設計：

1、超時時間 1s ，喂狗時間 500ms

2、看門狗任務優先級最高

3、每個任務發送信號量給看門狗任務，看門狗任務判斷是否收到了全部任務信號量，然后再決定是否喂狗。

看似合理，但其實有許多問題，接下來一個一個討論。

超時時間？

首先是超時時間問題，設計 1s 超時時間，500ms 喂狗，這對喂狗功能本身來說是沒有問題的，但這顯得過于嚴苛了，因為只要你某個任務運行超過了 1s，那很容易造成重啟現象，雖然說一個任務持續運行 1 s 也算是個不大不小的問題，但你要知道，看門狗是應對極其嚴重問題下的緊急措施，這種運行緩慢只是體驗不好，如果經常發生，在研發階段就應該解決，如果是偶發的，那么對應客戶來說，基本是感知不到的。

而這么短的時間就完成重啟，你可能很難從外部現象分清到底是因為電源、復位引腳還是看門狗導致的重啟，在沒有日志情況下，增大排查范圍。

如果我們能設置成10多秒的超時時間，那么我們很容易就能從表象發現，產品停止工作了，然后我們有足夠的時間運用魚鷹之前介紹的調試方法《BUG 終結者，現場抓獲！|顛覆認知》抓取到現場環境，這對定位這種偶發性問題非常有效（目前所待的兩個公司看門狗超時時間都設置在 10 s 以上）。

不過每種產品要求不同，對超時時間也不盡相同，所以自行決定即可（時間要求嚴格者，可考慮使用窗口看門狗）。

優先級和信號量？

第二點，優先級最高？在魚鷹看來，這絕對不行，這和把看門狗功能放在中斷中執行沒什么兩樣。

這里和第三點結合一起討論。

通過每個任務設置信號量的方式，確實保證了每個任務都正常運行，但真的合適嗎？

首先每個任務增加信號量，對系統資源是一大消耗，其次你能保證后續的開發人員在增加任務時能遵照你的設計要求寫代碼嗎？不一定吧。?

一旦增加新任務而未增加這個喂狗信號量，那么這個新任務的死活，看門狗可就無能為力了。因為看門狗任務優先級最高，只要現有信號量接收到了，就一定會喂狗，那么新任務可監控不了。

另外有些任務在設計時，可能就是很長時間才運行一次（如外部中斷觸發），那么這種任務肯定要因為你這個設計而不得不做出修改。

還有些任務走了異常分支，并沒有釋放CPU的行為（如delay），卻能正常釋放信號量，那么也是很難發現的。

而將看門狗任務優先級設計成最低（建議在空閑任務執行，這樣它一定是最低的，不會被人為修改），那么不管后面的人怎么添加新任務，只要新任務死循環，不釋放 CPU（低優先級任務無法運行，包括看門狗任務），那么一定會被感知到，從而使看門狗復位。

而為了保證一些關鍵代碼一定會被執行，可以設計一個變量，每個 bit 是一處關鍵代碼（在關鍵代碼執行后置 1），這樣只要在喂狗前判斷這個變量相關位是否設置即可。就是要注意該變量的保護，如關中斷。

這樣通過低優先級+位域的方式，就保證了其它任務一定都能被執行到，并且對關鍵代碼也做了進一步運行保證，使看門狗功能最大化。

　　審核編輯：湯梓紅