新聞中心

        EEPW首頁 > 嵌入式系統 > 設計應用 > 多任務系統看門狗的實現

        多任務系統看門狗的實現

        作者: 時間:2013-04-06 來源:網絡 收藏
        分硬件和軟件。硬件看門狗是利用一個定時器電路,其定時輸出連接到電路的復位端,程序在一定時間范圍內對定時器清零(俗稱“喂狗”),因此程序正常工作時,定時器總不能溢出,也就不能產生

        如果程序出現故障,不在定時周期內復位看門狗,就使得看門狗定時器溢出產生并重啟系統。軟件看門狗原理上一樣,只是將硬件電路上的定時器用處理器的內部定時器代替,這樣可以簡化硬件電路設計,但在可靠性方面不如硬件定時器,比如系統內部定時器自身發生故障就無法檢測到。當然也有通過雙定時器相互監視,這不僅加大系統開銷,也不能解決全部問題,比如中斷系統故障導致定時器中斷失效。

        看門狗本身不是用來解決系統出現的問題,在調試過程中發現的故障應該要查改設計本身的錯誤。加入看門狗目的是對一些程序潛在錯誤和惡劣環境干擾等因素導致系統死機而在無人干預情況下自動恢復系統正常工作狀態。看門狗也不能完全避免故障造成的損失,畢竟從發現故障到系統復位恢復正常這段時間內怠工。同時一些系統也需要復位前保護現場數據,重啟后恢復現場數據,這可能也需要一筆軟硬件的開銷。

        多任務系統看門狗的實現

        圖1:(a) 看門狗示意圖
        ;(b) 相應的看門狗復位邏輯圖。

          在單任務系統中看門狗工作原理如上所述,容易實現。在中情況稍為復雜。假如每個任務都像單任務系統那么做,如圖1(a)所示,只要有一個任務正常工作并定期“喂狗”,看門狗定時器就不會溢出。除非所有的任務都故障,才能使得看門狗定時器溢出而復位,如圖1(b)。

          而往往我們需要的是只要有一個任務故障,系統就要求復位。或者選擇幾個關鍵的任務接受監視,只要一個任務出問題系統就要求復位,如圖2(a)所示,相應的看門狗復位邏輯如圖2(b)所示。

          在中通過創建一個監視任務TaskMonitor,它的優先級高于被監視的任務群Task1、Task2...Taskn。TaskMonitor在Task1~Taskn正常工作情況下,一定時間內對硬件看門狗定時器清零。如果被監視任務群有一個Task_x出現故障,TaskMonitor就不對看門狗定時器清零,也就達到被監視任務出現故障時系統自動重啟的目的。另外任務TaskMonitor自身出故障時,也不能及時對看門狗定時器清零,看門狗也能自動復位重啟。接下來需要解決一個問題是:監視任務如何有效監視被監視的任務群。

        多任務系統看門狗的實現

        圖2:(a) 多任務系統看門狗示意圖;(b) 正確的看門狗復位邏輯圖。

          在TaskMonitor中定義一組結構體來模擬看門狗定時器組,

          typedef STruct

          {

          UINT32 CurCnt, LastCnt;

          BOOL RunState;

          int taskID;

          } STRUCT_WATCH_DOG;


        上一頁 1 2 下一頁

        評論


        相關推薦

        技術專區

        關閉
        主站蜘蛛池模板: 安吉县| 关岭| 平安县| 琼海市| 罗源县| 陵川县| 同心县| 荥阳市| 西充县| 同德县| 绥滨县| 兖州市| 偏关县| 抚顺市| 南通市| 富裕县| 大连市| 彰化县| 新绛县| 鲜城| 宕昌县| 阿克苏市| 通海县| 望城县| 政和县| 无极县| 平安县| 怀宁县| 和顺县| 城口县| 林口县| 璧山县| 安国市| 淮南市| 陵水| 襄汾县| 新巴尔虎右旗| 鸡东县| 通州市| 济南市| 厦门市|