多任務(wù)系統(tǒng)看門狗的實(shí)現(xiàn)
發(fā)布時(shí)間:2007/8/24 0:00:00 訪問次數(shù):376
看門狗分硬件看門狗和軟件看門狗。硬件看門狗是利用一個(gè)定時(shí)器電路,其定時(shí)輸出連接到電路的復(fù)位端,程序在一定時(shí)間范圍內(nèi)對定時(shí)器清零(俗稱“喂狗”),因此程序正常工作時(shí),定時(shí)器總不能溢出,也就不能產(chǎn)生復(fù)位信號。如果程序出現(xiàn)故障,不在定時(shí)周期內(nèi)復(fù)位看門狗,就使得看門狗定時(shí)器溢出產(chǎn)生復(fù)位信號并重啟系統(tǒng)。軟件看門狗原理上一樣,只是將硬件電路上的定時(shí)器用處理器的內(nèi)部定時(shí)器代替,這樣可以簡化硬件電路設(shè)計(jì),但在可靠性方面不如硬件定時(shí)器,比如系統(tǒng)內(nèi)部定時(shí)器自身發(fā)生故障就無法檢測到。當(dāng)然也有通過雙定時(shí)器相互監(jiān)視,這不僅加大系統(tǒng)開銷,也不能解決全部問題,比如中斷系統(tǒng)故障導(dǎo)致定時(shí)器中斷失效。
看門狗本身不是用來解決系統(tǒng)出現(xiàn)的問題,在調(diào)試過程中發(fā)現(xiàn)的故障應(yīng)該要查改設(shè)計(jì)本身的錯(cuò)誤。加入看門狗目的是對一些程序潛在錯(cuò)誤和惡劣環(huán)境干擾等因素導(dǎo)致系統(tǒng)死機(jī)而在無人干預(yù)情況下自動(dòng)恢復(fù)系統(tǒng)正常工作狀態(tài)?撮T狗也不能完全避免故障造成的損失,畢竟從發(fā)現(xiàn)故障到系統(tǒng)復(fù)位恢復(fù)正常這段時(shí)間內(nèi)怠工。同時(shí)一些系統(tǒng)也需要復(fù)位前保護(hù)現(xiàn)場數(shù)據(jù),重啟后恢復(fù)現(xiàn)場數(shù)據(jù),這可能也需要一筆軟硬件的開銷。
圖1:(a) 多任務(wù)系統(tǒng)看門狗示意圖;(b) 相應(yīng)的看門狗復(fù)位邏輯圖。
在單任務(wù)系統(tǒng)中看門狗工作原理如上所述,容易實(shí)現(xiàn)。在多任務(wù)系統(tǒng)中情況稍為復(fù)雜。假如每個(gè)任務(wù)都像單任務(wù)系統(tǒng)那么做,如圖1(a)所示,只要有一個(gè)任務(wù)正常工作并定期“喂狗”,看門狗定時(shí)器就不會溢出。除非所有的任務(wù)都故障,才能使得看門狗定時(shí)器溢出而復(fù)位,如圖1(b)。
而往往我們需要的是只要有一個(gè)任務(wù)故障,系統(tǒng)就要求復(fù)位;蛘哌x擇幾個(gè)關(guān)鍵的任務(wù)接受監(jiān)視,只要一個(gè)任務(wù)出問題系統(tǒng)就要求復(fù)位,如圖2(a)所示,相應(yīng)的看門狗復(fù)位邏輯如圖2(b)所示。
在多任務(wù)系統(tǒng)中通過創(chuàng)建一個(gè)監(jiān)視任務(wù)TaskMonitor,它的優(yōu)先級高于被監(jiān)視的任務(wù)群Task1、Task2...Taskn。TaskMonitor在Task1~Taskn正常工作情況下,一定時(shí)間內(nèi)對硬件看門狗定時(shí)器清零。如果被監(jiān)視任務(wù)群有一個(gè)Task_x出現(xiàn)故障,TaskMonitor就不對看門狗定時(shí)器清零,也就達(dá)到被監(jiān)視任務(wù)出現(xiàn)故障時(shí)系統(tǒng)自動(dòng)重啟的目的。另外任務(wù)TaskMonitor自身出故障時(shí),也不能及時(shí)對看門狗定時(shí)器清零,看門狗也能自動(dòng)復(fù)位重啟。接下來需要解決一個(gè)問題是:監(jiān)視任務(wù)如何有效監(jiān)視被監(jiān)視的任務(wù)群。
圖2:(a) 多任務(wù)系統(tǒng)看門狗示意圖;(b) 正確的看門狗復(fù)位邏輯圖。
在TaskMonitor中定義一組結(jié)構(gòu)體來模擬看門狗定時(shí)器組,
typedef struct
{
UINT32 CurCnt, LastCnt;
BOOL RunState;
int taskID;
} STRUCT_WATCH_DOG;
該結(jié)構(gòu)體包括被監(jiān)視的任務(wù)號taskID,用來模擬“喂狗”的變量CurCnt、LastCnt(具體含義見下文),看門狗狀態(tài)標(biāo)志RunState用來控制當(dāng)前任務(wù)是否接受監(jiān)視。
被監(jiān)視的任務(wù)Task1~Taskn調(diào)用自定義函數(shù)CreateWatchDog(int taskid)來創(chuàng)建看門狗,被監(jiān)視任務(wù)一段時(shí)間內(nèi)要求“喂狗”,調(diào)用ResetWatchDog(int taskid),這個(gè)“喂狗”動(dòng)作實(shí)質(zhì)就是對看門狗定時(shí)器結(jié)構(gòu)體中的變量CurCnt加1操作。TaskMonitor大部分時(shí)間處于延時(shí)狀態(tài),假設(shè)硬件看門狗定時(shí)是2秒,監(jiān)視任務(wù)可以延時(shí)1.5秒,接著對創(chuàng)建的看門狗定時(shí)器組一一檢驗(yàn),延時(shí)前保存CurCnt的當(dāng)前值到LastCnt,延時(shí)后比較CurCnt與LastCnt是否相等,都不相等系統(tǒng)才是正常的。需要注意的是CurCnt和LastCnt數(shù)據(jù)字節(jié)數(shù)太小,而“喂狗”過于頻繁,可能出現(xiàn)CurCnt加1操作達(dá)到一個(gè)循環(huán)而與LastCnt相等。
如果有任意一組的CurCnt等于LastCnt,認(rèn)為對應(yīng)接受監(jiān)視的任務(wù)沒有“喂狗”動(dòng)作,也就檢測到該任務(wù)出現(xiàn)故障需要重啟,這時(shí)候TaskMonitor不對硬件看門狗定時(shí)器清零,或者延時(shí)很長的時(shí)間,比如10秒,足以使得系統(tǒng)重啟。反之,系統(tǒng)正常,Task1~Taskn定期對TaskMonitor“喂狗”,TaskMonitor又定期對硬件看門狗“喂狗”,系統(tǒng)就得不到復(fù)位。還有一點(diǎn),被監(jiān)視任務(wù)可以通過調(diào)用PauseWatchDog(int taskid)來取消對應(yīng)的看門狗,實(shí)際上就是對STRUCT_WATCH_DOG結(jié)構(gòu)體中的RunState操作,該標(biāo)志體現(xiàn)看門狗有效與否。
這種方式可監(jiān)視的最大任務(wù)數(shù)由STRUCT_WATCH_DOG結(jié)構(gòu)數(shù)據(jù)的個(gè)數(shù)決定。程序中應(yīng)該有一個(gè)變量記錄當(dāng)前已創(chuàng)建的看門狗數(shù),判斷被監(jiān)視任務(wù)Task1~Taskn是否“喂狗”只需比較CurCnt與LastCnt的值n次。
圖3:系統(tǒng)復(fù)位邏輯圖。
硬件看門狗監(jiān)視TaskMonitor任務(wù),TaskMonitor任務(wù)又監(jiān)視其他的被監(jiān)視任務(wù)Task1~Taskn,形成這樣一種鏈條。這種方式系統(tǒng)的故障圖表示如圖3所示。被監(jiān)視任務(wù)Task1~Taskn及TaskMonitor都是或的關(guān)系,因此被監(jiān)視的任一任務(wù)發(fā)生故障,硬件電路看門狗就能復(fù)位。
為實(shí)現(xiàn)多任務(wù)系統(tǒng)的看門狗監(jiān)視功能額外增加了TaskMonit
看門狗分硬件看門狗和軟件看門狗。硬件看門狗是利用一個(gè)定時(shí)器電路,其定時(shí)輸出連接到電路的復(fù)位端,程序在一定時(shí)間范圍內(nèi)對定時(shí)器清零(俗稱“喂狗”),因此程序正常工作時(shí),定時(shí)器總不能溢出,也就不能產(chǎn)生復(fù)位信號。如果程序出現(xiàn)故障,不在定時(shí)周期內(nèi)復(fù)位看門狗,就使得看門狗定時(shí)器溢出產(chǎn)生復(fù)位信號并重啟系統(tǒng)。軟件看門狗原理上一樣,只是將硬件電路上的定時(shí)器用處理器的內(nèi)部定時(shí)器代替,這樣可以簡化硬件電路設(shè)計(jì),但在可靠性方面不如硬件定時(shí)器,比如系統(tǒng)內(nèi)部定時(shí)器自身發(fā)生故障就無法檢測到。當(dāng)然也有通過雙定時(shí)器相互監(jiān)視,這不僅加大系統(tǒng)開銷,也不能解決全部問題,比如中斷系統(tǒng)故障導(dǎo)致定時(shí)器中斷失效。
看門狗本身不是用來解決系統(tǒng)出現(xiàn)的問題,在調(diào)試過程中發(fā)現(xiàn)的故障應(yīng)該要查改設(shè)計(jì)本身的錯(cuò)誤。加入看門狗目的是對一些程序潛在錯(cuò)誤和惡劣環(huán)境干擾等因素導(dǎo)致系統(tǒng)死機(jī)而在無人干預(yù)情況下自動(dòng)恢復(fù)系統(tǒng)正常工作狀態(tài)?撮T狗也不能完全避免故障造成的損失,畢竟從發(fā)現(xiàn)故障到系統(tǒng)復(fù)位恢復(fù)正常這段時(shí)間內(nèi)怠工。同時(shí)一些系統(tǒng)也需要復(fù)位前保護(hù)現(xiàn)場數(shù)據(jù),重啟后恢復(fù)現(xiàn)場數(shù)據(jù),這可能也需要一筆軟硬件的開銷。
圖1:(a) 多任務(wù)系統(tǒng)看門狗示意圖;(b) 相應(yīng)的看門狗復(fù)位邏輯圖。
在單任務(wù)系統(tǒng)中看門狗工作原理如上所述,容易實(shí)現(xiàn)。在多任務(wù)系統(tǒng)中情況稍為復(fù)雜。假如每個(gè)任務(wù)都像單任務(wù)系統(tǒng)那么做,如圖1(a)所示,只要有一個(gè)任務(wù)正常工作并定期“喂狗”,看門狗定時(shí)器就不會溢出。除非所有的任務(wù)都故障,才能使得看門狗定時(shí)器溢出而復(fù)位,如圖1(b)。
而往往我們需要的是只要有一個(gè)任務(wù)故障,系統(tǒng)就要求復(fù)位;蛘哌x擇幾個(gè)關(guān)鍵的任務(wù)接受監(jiān)視,只要一個(gè)任務(wù)出問題系統(tǒng)就要求復(fù)位,如圖2(a)所示,相應(yīng)的看門狗復(fù)位邏輯如圖2(b)所示。
在多任務(wù)系統(tǒng)中通過創(chuàng)建一個(gè)監(jiān)視任務(wù)TaskMonitor,它的優(yōu)先級高于被監(jiān)視的任務(wù)群Task1、Task2...Taskn。TaskMonitor在Task1~Taskn正常工作情況下,一定時(shí)間內(nèi)對硬件看門狗定時(shí)器清零。如果被監(jiān)視任務(wù)群有一個(gè)Task_x出現(xiàn)故障,TaskMonitor就不對看門狗定時(shí)器清零,也就達(dá)到被監(jiān)視任務(wù)出現(xiàn)故障時(shí)系統(tǒng)自動(dòng)重啟的目的。另外任務(wù)TaskMonitor自身出故障時(shí),也不能及時(shí)對看門狗定時(shí)器清零,看門狗也能自動(dòng)復(fù)位重啟。接下來需要解決一個(gè)問題是:監(jiān)視任務(wù)如何有效監(jiān)視被監(jiān)視的任務(wù)群。
圖2:(a) 多任務(wù)系統(tǒng)看門狗示意圖;(b) 正確的看門狗復(fù)位邏輯圖。
在TaskMonitor中定義一組結(jié)構(gòu)體來模擬看門狗定時(shí)器組,
typedef struct
{
UINT32 CurCnt, LastCnt;
BOOL RunState;
int taskID;
} STRUCT_WATCH_DOG;
該結(jié)構(gòu)體包括被監(jiān)視的任務(wù)號taskID,用來模擬“喂狗”的變量CurCnt、LastCnt(具體含義見下文),看門狗狀態(tài)標(biāo)志RunState用來控制當(dāng)前任務(wù)是否接受監(jiān)視。
被監(jiān)視的任務(wù)Task1~Taskn調(diào)用自定義函數(shù)CreateWatchDog(int taskid)來創(chuàng)建看門狗,被監(jiān)視任務(wù)一段時(shí)間內(nèi)要求“喂狗”,調(diào)用ResetWatchDog(int taskid),這個(gè)“喂狗”動(dòng)作實(shí)質(zhì)就是對看門狗定時(shí)器結(jié)構(gòu)體中的變量CurCnt加1操作。TaskMonitor大部分時(shí)間處于延時(shí)狀態(tài),假設(shè)硬件看門狗定時(shí)是2秒,監(jiān)視任務(wù)可以延時(shí)1.5秒,接著對創(chuàng)建的看門狗定時(shí)器組一一檢驗(yàn),延時(shí)前保存CurCnt的當(dāng)前值到LastCnt,延時(shí)后比較CurCnt與LastCnt是否相等,都不相等系統(tǒng)才是正常的。需要注意的是CurCnt和LastCnt數(shù)據(jù)字節(jié)數(shù)太小,而“喂狗”過于頻繁,可能出現(xiàn)CurCnt加1操作達(dá)到一個(gè)循環(huán)而與LastCnt相等。
如果有任意一組的CurCnt等于LastCnt,認(rèn)為對應(yīng)接受監(jiān)視的任務(wù)沒有“喂狗”動(dòng)作,也就檢測到該任務(wù)出現(xiàn)故障需要重啟,這時(shí)候TaskMonitor不對硬件看門狗定時(shí)器清零,或者延時(shí)很長的時(shí)間,比如10秒,足以使得系統(tǒng)重啟。反之,系統(tǒng)正常,Task1~Taskn定期對TaskMonitor“喂狗”,TaskMonitor又定期對硬件看門狗“喂狗”,系統(tǒng)就得不到復(fù)位。還有一點(diǎn),被監(jiān)視任務(wù)可以通過調(diào)用PauseWatchDog(int taskid)來取消對應(yīng)的看門狗,實(shí)際上就是對STRUCT_WATCH_DOG結(jié)構(gòu)體中的RunState操作,該標(biāo)志體現(xiàn)看門狗有效與否。
這種方式可監(jiān)視的最大任務(wù)數(shù)由STRUCT_WATCH_DOG結(jié)構(gòu)數(shù)據(jù)的個(gè)數(shù)決定。程序中應(yīng)該有一個(gè)變量記錄當(dāng)前已創(chuàng)建的看門狗數(shù),判斷被監(jiān)視任務(wù)Task1~Taskn是否“喂狗”只需比較CurCnt與LastCnt的值n次。
圖3:系統(tǒng)復(fù)位邏輯圖。
硬件看門狗監(jiān)視TaskMonitor任務(wù),TaskMonitor任務(wù)又監(jiān)視其他的被監(jiān)視任務(wù)Task1~Taskn,形成這樣一種鏈條。這種方式系統(tǒng)的故障圖表示如圖3所示。被監(jiān)視任務(wù)Task1~Taskn及TaskMonitor都是或的關(guān)系,因此被監(jiān)視的任一任務(wù)發(fā)生故障,硬件電路看門狗就能復(fù)位。
為實(shí)現(xiàn)多任務(wù)系統(tǒng)的看門狗監(jiān)視功能額外增加了TaskMonit
熱門點(diǎn)擊
- 寄存器和移位寄存器
- 確定準(zhǔn)諧振反激式變換器主要設(shè)計(jì)參數(shù)的實(shí)用方法
- 稅控收款機(jī)專用IC卡應(yīng)用研究 張 劍,郭玉東
- 無速度傳感器異步電機(jī)矢量控制方法
- 超聲波測距與嵌入式SPT-K控制器在汽車自動(dòng)
- 新一代DRSEM系統(tǒng)SEMViSiOnG2
- 四探針技術(shù)測量薄層電阻的原理及應(yīng)用 劉新福,
- 黑白電視機(jī)高壓包的繞制
- 射頻識別電路中高頻功放的設(shè)計(jì)
- 無源元件對音質(zhì)的影響與改善的新技術(shù)
推薦技術(shù)資料
- 按鈕與燈的互動(dòng)實(shí)例
- 現(xiàn)在趕快去看看這個(gè)目錄卞有什么。FGA15N120AN... [詳細(xì)]
- CV/CC InnoSwitch3-AQ 開
- URF1DxxM-60WR3系
- 1-6W URA24xxN-x
- 閉環(huán)磁通門信號調(diào)節(jié)芯片NSDRV401
- SK-RiSC-SOM-H27X-V1.1應(yīng)
- RISC技術(shù)8位微控制器參數(shù)設(shè)
- 多媒體協(xié)處理器SM501在嵌入式系統(tǒng)中的應(yīng)用
- 基于IEEE802.11b的EPA溫度變送器
- QUICCEngine新引擎推動(dòng)IP網(wǎng)絡(luò)革新
- SoC面世八年后的產(chǎn)業(yè)機(jī)遇
- MPC8xx系列處理器的嵌入式系統(tǒng)電源設(shè)計(jì)
- dsPIC及其在交流變頻調(diào)速中的應(yīng)用研究