前言
一個學(xué)員在學(xué)習(xí) uCOS 系統(tǒng)過程中,對看門狗任務(wù)的優(yōu)先級產(chǎn)生了疑惑,到底該把喂狗任務(wù)優(yōu)先級設(shè)置成最高還是最低好?
這里談?wù)剛€人看法,首先給出結(jié)論,最低,甚至是在空閑任務(wù)運行(使用鉤子函數(shù))。
理由
首先我們要知道看門狗的工作是什么?為什么要設(shè)置看門狗。
很多產(chǎn)品出廠時,都會開啟看門狗,這是產(chǎn)品運行的最后保障,可以在出現(xiàn)軟件 bug 時(如hardfault,死循環(huán)等),及時恢復(fù)運行,讓產(chǎn)品可以重新繼續(xù)工作下去,但這不意味著萬事大吉,一旦發(fā)現(xiàn)了看門狗引起的復(fù)位問題(可以通過寄存器標(biāo)志位查看因何復(fù)位),一定要找到問題根因,否則出現(xiàn)了一次,后面一定還會不停出現(xiàn),用戶體驗相當(dāng)不好。
那么我們應(yīng)該怎么設(shè)置看門狗的功能呢?這個學(xué)員準(zhǔn)備這么設(shè)計:
1、超時時間 1s ,喂狗時間 500ms
2、看門狗任務(wù)優(yōu)先級最高
3、每個任務(wù)發(fā)送信號量給看門狗任務(wù),看門狗任務(wù)判斷是否收到了全部任務(wù)信號量,然后再決定是否喂狗。
看似合理,但其實有許多問題,接下來一個一個討論。
超時時間?
首先是超時時間問題,設(shè)計 1s 超時時間,500ms 喂狗,這對喂狗功能本身來說是沒有問題的,但這顯得過于嚴(yán)苛了,因為只要你某個任務(wù)運行超過了 1s,那很容易造成重啟現(xiàn)象,雖然說一個任務(wù)持續(xù)運行 1 s 也算是個不大不小的問題,但你要知道,看門狗是應(yīng)對極其嚴(yán)重問題下的緊急措施,這種運行緩慢只是體驗不好,如果經(jīng)常發(fā)生,在研發(fā)階段就應(yīng)該解決,如果是偶發(fā)的,那么對應(yīng)客戶來說,基本是感知不到的。
而這么短的時間就完成重啟,你可能很難從外部現(xiàn)象分清到底是因為電源、復(fù)位引腳還是看門狗導(dǎo)致的重啟,在沒有日志情況下,增大排查范圍。
如果我們能設(shè)置成10多秒的超時時間,那么我們很容易就能從表象發(fā)現(xiàn),產(chǎn)品停止工作了,然后我們有足夠的時間抓取到現(xiàn)場環(huán)境,這對定位這種偶發(fā)性問題非常有效(目前所待的兩個公司看門狗超時時間都設(shè)置在 10 s 以上)。
不過每種產(chǎn)品要求不同,對超時時間也不盡相同,所以自行決定即可(時間要求嚴(yán)格者,可考慮使用窗口看門狗)。
優(yōu)先級和信號量?
第二點,優(yōu)先級最高?在魚鷹看來,這絕對不行,這和把看門狗功能放在中斷中執(zhí)行沒什么兩樣。
這里和第三點結(jié)合一起討論。
通過每個任務(wù)設(shè)置信號量的方式,確實保證了每個任務(wù)都正常運行,但真的合適嗎?
首先每個任務(wù)增加信號量,對系統(tǒng)資源是一大消耗,其次你能保證后續(xù)的開發(fā)人員在增加任務(wù)時能遵照你的設(shè)計要求寫代碼嗎?不一定吧。
一旦增加新任務(wù)而未增加這個喂狗信號量,那么這個新任務(wù)的死活,看門狗可就無能為力了。因為看門狗任務(wù)優(yōu)先級最高,只要現(xiàn)有信號量接收到了,就一定會喂狗,那么新任務(wù)可監(jiān)控不了。
另外有些任務(wù)在設(shè)計時,可能就是很長時間才運行一次(如外部中斷觸發(fā)),那么這種任務(wù)肯定要因為你這個設(shè)計而不得不做出修改。
還有些任務(wù)走了異常分支,并沒有釋放CPU的行為(如delay),卻能正常釋放信號量,那么也是很難發(fā)現(xiàn)的。
而將看門狗任務(wù)優(yōu)先級設(shè)計成最低(建議在空閑任務(wù)執(zhí)行,這樣它一定是最低的,不會被人為修改),那么不管后面的人怎么添加新任務(wù),只要新任務(wù)死循環(huán),不釋放 CPU(低優(yōu)先級任務(wù)無法運行,包括看門狗任務(wù)),那么一定會被感知到,從而使看門狗復(fù)位。
而為了保證一些關(guān)鍵代碼一定會被執(zhí)行,可以設(shè)計一個變量,每個 bit 是一處關(guān)鍵代碼(在關(guān)鍵代碼執(zhí)行后置 1),這樣只要在喂狗前判斷這個變量相關(guān)位是否設(shè)置即可。就是要注意該變量的保護,如關(guān)中斷。
這樣通過低優(yōu)先級+位域的方式,就保證了其它任務(wù)一定都能被執(zhí)行到,并且對關(guān)鍵代碼也做了進一步運行保證,使看門狗功能最大化。
審核編輯:劉清
-
看門狗
+關(guān)注
關(guān)注
10文章
566瀏覽量
70949 -
中斷
+關(guān)注
關(guān)注
5文章
900瀏覽量
41757 -
信號量
+關(guān)注
關(guān)注
0文章
53瀏覽量
8374 -
ucos系統(tǒng)
+關(guān)注
關(guān)注
0文章
2瀏覽量
6017
原文標(biāo)題:談?wù)効撮T狗優(yōu)先級
文章出處:【微信號:emOsprey,微信公眾號:魚鷹談單片機】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
第8章 任務(wù)優(yōu)先級修改
STM32中斷優(yōu)先級徹底講解
UCOSII實驗1,任務(wù)調(diào)度的實驗中為什么把最低優(yōu)先級的給了開始任務(wù)?
UC/OS-II系統(tǒng)為什么例子里還能設(shè)置按鍵任務(wù)優(yōu)先級為3
ucos3中systick中斷的優(yōu)先級在哪里修改?
COSII移植例程里開始任務(wù)的優(yōu)先級為什么是最低的?
軟件定時器的優(yōu)先級與任務(wù)的優(yōu)先級是同一個東西嗎?
DSP中斷如何設(shè)置優(yōu)先級
鴻蒙內(nèi)核源碼:32級優(yōu)先級的進程和線程調(diào)度
2.FreeRTOS中斷優(yōu)先級和任務(wù)優(yōu)先級
![2.FreeRTOS中斷<b class='flag-5'>優(yōu)先級</b>和<b class='flag-5'>任務(wù)</b><b class='flag-5'>優(yōu)先級</b>](https://file.elecfans.com/web1/M00/D9/4E/pIYBAF_1ac2Ac0EEAABDkS1IP1s689.png)
STM32F103芯片中斷優(yōu)先級以及FreeRTOS優(yōu)先級設(shè)置
![STM32F103芯片中斷<b class='flag-5'>優(yōu)先級</b>以及FreeRTOS<b class='flag-5'>優(yōu)先級</b><b class='flag-5'>設(shè)置</b>](https://file.elecfans.com/web1/M00/D9/4E/pIYBAF_1ac2Ac0EEAABDkS1IP1s689.png)
評論