uC/OS-II 系統的多任務(wù)看門(mén)狗設計

在嵌入式系統中為提高微型機系統的可靠性和安全性, 常用的方法就是使用“看門(mén)狗”。看門(mén)狗分硬件看門(mén)狗和軟件看門(mén)狗。硬件看門(mén)狗采用“看門(mén)狗”電路, 通過(guò)定時(shí)器, 對微型機任務(wù)即“喂狗”在運行時(shí)間上加以約束, 任務(wù)必須在最大指定時(shí)間范圍內完成, 否則重啟系統。軟件看門(mén)狗采用處理器內部定時(shí)器, 把任務(wù)的理論最大運行時(shí)間作為時(shí)間約束, 如果該任務(wù)超過(guò)了這個(gè)時(shí)間跨度, 則強制退出本次任務(wù)。上述看門(mén)狗采用的是單任務(wù)的順序機制, 容易實(shí)現。在多任務(wù)系統中情況稍為復雜, 如果每個(gè)任務(wù)都像單任務(wù)系統那樣,只要有一個(gè)任務(wù)正常工作并定期“喂狗”,看門(mén)狗定時(shí)器就不會(huì )溢出, 而只有所有任務(wù)都出現問(wèn)題時(shí), 定時(shí)器才會(huì )溢出。重慶師范大學(xué)葉幫利老師曾在windows 系統中探討和解決了這個(gè)問(wèn)題[ 1 ] , 在嵌入式系統中也有人曾談到過(guò)[ 2 ] , 但是卻沒(méi)有具體實(shí)現方法的敘述。

文中把u C / O S - I I 操作系統移植到PHILIPS 公司生產(chǎn)的LPC2132 內核中,基于系統的消息機制和優(yōu)先級權限, 設置了一個(gè)優(yōu)先級最高的任務(wù)作為監視器對微型機上運行的所有任務(wù)進(jìn)行監控, 只要一個(gè)任務(wù)出現故障, 該監視任務(wù)就延遲喂狗, 使定時(shí)器溢出, 重啟系統, 以保障微型機及所有任務(wù)處于長(cháng)期穩定的運行狀態(tài)。

1 系統概述

1 . 1 硬件和開(kāi)發(fā)環(huán)境簡(jiǎn)介

把uC/OS-II 操作系統移植到LPC2132的開(kāi)發(fā)板中。LPC2132 是一個(gè)支持實(shí)時(shí)仿真和跟蹤的32 位ARM7TDMI-STM 核微處理器,帶64kB 高速FLASH 存儲器,4 個(gè)通信接口, 2 個(gè)32 位定時(shí)器, 1 個(gè)10 位8 路ADC,2 個(gè)硬件接口,47 個(gè)GPIO 以及多達9個(gè)邊沿或電平觸發(fā)的外部中斷, 完全能滿(mǎn)足一般應用程序及擴展的需求。

uC/OS-II 是一個(gè)搶占式多任務(wù)實(shí)時(shí)操作系統, 其源代碼公開(kāi)、可移植性強, 有著(zhù)易用性、易開(kāi)發(fā)性和普及性的特點(diǎn)。uC/OS- Ⅱ最多可以管理64 個(gè)任務(wù), 這些任務(wù)通常都是一個(gè)無(wú)限循環(huán)的函數。在目前的版本中, 保留了優(yōu)先級為0 、1 、2 、3 、OS_LOWEST_PRIO-3、OS_LOWEST_PRIO-2 、O S _ L O W E S T _ P R I O - 1 、OS_LOWEST_PRIO 的任務(wù),所以用戶(hù)可以同時(shí)擁有5 6 個(gè)任務(wù), 足以滿(mǎn)足用戶(hù)設計的各種要求。

1 . 2 系統實(shí)現的功能

在多任務(wù)系統中, 往往希望有一個(gè)任務(wù)出問(wèn)題時(shí)把該任務(wù)重啟, 而不重啟整個(gè)系統, 以達到不影響其他關(guān)鍵任務(wù)運行的目的, 在多次重啟該任務(wù)無(wú)效時(shí)再重啟系統。當系統的主程序出現錯誤或者系統硬件出現問(wèn)題時(shí)重啟系統?；谝陨戏治?a class="contentlabel" href="http://dyxdggzs.com/news/listbylabel/label/設計">設計的看門(mén)狗主要實(shí)現以下功能。

( 1 ) 當某個(gè)任務(wù)出現異常時(shí), 由軟件看門(mén)狗重啟該任務(wù)。

( 2 ) 當多次重啟某一任務(wù)失敗時(shí), 重啟系統。

( 3 ) 當操作系統本身出現異常時(shí), 或者系統硬件出現異常時(shí), 由軟件看門(mén)狗或者是硬件看門(mén)狗重新啟動(dòng)微處理器。

2 多任務(wù)看門(mén)狗監控原理

結合LPC2132 內置硬件看門(mén)狗和uC/O S - Ⅱ操作系統, 設置了一個(gè)優(yōu)先級別最高的任務(wù)作為監視器監視各應用任務(wù)是否正常運行, 該監視器稱(chēng)為軟件看門(mén)狗。該任務(wù)對每個(gè)被監視任務(wù)都設定一個(gè)計時(shí)器, 被監視任務(wù)在設定的時(shí)間內對對應的定時(shí)器定時(shí)清零, 稱(chēng)為“喂軟狗”。在被監視的任務(wù)都正常工作的情況下, 軟件看門(mén)狗對內置硬件看門(mén)狗定時(shí)器周期性清零,稱(chēng)為“喂狗”。如果被監視任務(wù)群某個(gè)任務(wù)出現故障, 不能在設置的時(shí)間內對軟件看門(mén)狗“喂軟狗”, 與之對應的定時(shí)器溢出,系統內核發(fā)送指令, 把該任務(wù)的堆棧地址指到其起始地址, 復位該任務(wù), 如果在設定的次數內不能夠有效啟動(dòng)該任務(wù), 則延時(shí)“喂狗”, 硬件看門(mén)狗計數器溢出, 重啟系統。另外當監視器任務(wù)本身出現故障時(shí),也不能及時(shí)對看硬件看門(mén)狗定時(shí)器清零,重啟系統。

3 軟件實(shí)現

3 . 1 應用任務(wù)與軟件看門(mén)狗之間的通信

在多任務(wù)軟件看門(mén)狗與各應用任務(wù)間之間進(jìn)行信息傳遞時(shí), 每個(gè)應用任務(wù)都會(huì )對監視器發(fā)送運行狀態(tài)消息, 監視器任務(wù)也要對每個(gè)任務(wù)發(fā)送消息。在應用任務(wù)較多的情況下, 如果采用信箱進(jìn)行通訊, 會(huì )造成大量無(wú)效操作, 也使得編程變得繁瑣, 所以在監視器任務(wù)中采用消息隊列來(lái)實(shí)現與各應用任務(wù)間的消息傳遞, 而在各應用任務(wù)中設置兩個(gè)信箱, 一個(gè)用來(lái)對監視器消息隊列發(fā)送消息, 一個(gè)用來(lái)接收監視器任務(wù)消息隊列發(fā)送的消息。當某個(gè)應用任務(wù)在執行出錯時(shí),調用OSQPost()函數向監視器任務(wù)消息隊列發(fā)送消息, 監視器任務(wù)通過(guò)調用OSQPend()函數從消息隊列讀取該消息,然后調用OSMboxPost()函數向該應用任務(wù)的消息接收信箱發(fā)送代表不同意義的消息,該任務(wù)調用OSMboxPend()函數從信箱中讀取該消息后執行相應的操作。

3 . 2 多任務(wù)軟件看門(mén)狗的實(shí)現

多任務(wù)看門(mén)狗通過(guò)檢查各應用任務(wù)是否在規定的時(shí)間內對其“喂軟狗”來(lái)監測各任務(wù)的運行狀態(tài)。借助微處理器的定時(shí)器中斷機制, 為每個(gè)任務(wù)分配計時(shí)單元和運行標志, 由定時(shí)中斷依據運行標志狀態(tài)進(jìn)行獨立計時(shí)。當系統中的某任務(wù)空閑時(shí), 以小于“喂軟狗”設定的時(shí)間間隔為周期, 周期性地“喂軟狗”; 在該任務(wù)執行時(shí),預計執行所需的最長(cháng)耗時(shí), 并用稍大于該最大耗時(shí)的時(shí)間間隔設置監視器中定時(shí)器參數, 同時(shí)中斷周期性“喂軟狗”模塊, 啟動(dòng)監視器任務(wù)中的定時(shí)器倒計數。當該任務(wù)正常執行完畢時(shí), 發(fā)送信號“喂軟狗”,對定時(shí)器清零, 復位該任務(wù), 同時(shí)恢復周期性“喂軟狗”模塊; 當該任務(wù)執行出現異常時(shí), 不能在設定的時(shí)間間隔內對軟件看門(mén)狗清零, 使得監視器中相應的定時(shí)器溢出,監視器任務(wù)通過(guò)內核服務(wù)發(fā)送指令, 把該任務(wù)的堆棧地址指到其起始地址, 重啟該任務(wù), 同時(shí)累計其復位次數, 把該任務(wù)的計時(shí)器清零。

4 結語(yǔ)

結合LPC2132 內置硬件看門(mén)狗和uC/O S - Ⅱ操作系統, 設計了一種能夠實(shí)現多任務(wù)管理的軟件看門(mén)狗, 該看門(mén)狗不但能夠有效地監視各應用任務(wù), 也能夠在不影響其他任務(wù)正常運行的情況下, 重啟該任務(wù), 直至在多次重啟無(wú)效時(shí), 才重啟系統,達到了相互獨立的應用任務(wù)之間不會(huì )過(guò)于牽制的目的。另外該看門(mén)狗也能在主程序和硬件出問(wèn)題時(shí)自動(dòng)重啟, 確保系統長(cháng)時(shí)間穩定運行。