在傳統的嵌入式系統軟件設計中,多采用單任務順序機制。此機制的優勢在于流程直觀,但它常帶來一個重要的問題--系統安全性差,即程序運行中任一環節出錯都會導致系統混亂,只能依靠看門狗復位重新運行。在焊縫跟蹤系統中,弧光干擾嚴重,若存在單任務順序機制,雖存在多種硬件高層干擾措施,系統有時仍需頻繁復位以致無法達到系統。為此在焊縫軌跡智能跟蹤系統中,作者將實時嵌放式操作系統uC/OS-II用于單片機80c196的軟件設計中,并設計監視任務,較好地解決了該問題。uC/OS-II是一種免費的操作系統且源代碼公開,其可靠性已在許多應用中得到了證明。
1 系統概述
系統設計目標為:在TIG焊條件下,焊接速度為24cm/min時,焊頭與焊縫偏差小于1mm。
系統的設計思路為:采用電弧傳感器采集焊頭相對焊縫不同位置時的焊接電流信號,將此信號經信號處理得焊頭相對于焊縫的偏差置,此偏差量經控制運算后得相應的控制信號。將此控制信號輸出到電機,從而改變焊頭與焊縫的偏差。
系統的功能塊有信號采集、信號處理、控制運算、輸出等。另外由于本系統的弧光干擾嚴重,為防止程序運行中因一個環節出錯而導致系統混亂以致無法控制焊頭與焊縫的偏差,本系統設計了監視模塊用來及時糾錯。
系統結構圖如圖1所示,由外而內可分三層,分別為硬件電路層、任務層及操作系統層。
2 硬件電路層設計
本系統的硬件電路層包括一塊信號采集板和一塊驅動板。前者的用途在于從電弧傳感器獲取電流信號并將其轉換成電壓信號。此電流信號能有效表征焊頭與焊縫的位置關系,此電壓信號將被任務層的信號采集任務獲取。后者的用途在于制任務層中輸出任務產生的命令(此命令作用于單片機輸出口)傳輸到電機,從而改變焊頭和焊縫的偏差。
3 任務層設計
3.1 系統任務層組成及其優先權設置
系統任務層并行存在的幾個任務依其優先權從高到低依次為:監視任務、輸出任務、控制運算任務、信號處理任務、信號采集任務。優先權的設置由各任務的執行順序以及對系統安全性影響的大小決定。本系統采用靜態優先權,即運行過程中任務優先權不變。
3.2 任務的狀態
本系統中各任務的狀態有4種:等待態、就緒態、運行態以及中斷態。狀態的轉換關系如圖2所示。
當一個任務點用CPU時該任務處于運行態,其優先權必較所有就緒態任務優先權高。若系統運行導致就緒態某一任務的優行權高于運行態任務優先僅,則調用調度函數,運行態任務將喪失對CPU的占用權而轉為就緒態,優先權最高的就緒態任務轉為運行態。某一時刻只能有一個任務處于運行態。任務在就緒態和運行態間的轉化被稱為任務切換。
當運行態的任務期待某一消息時(即別的任務和該任務的數據傳遞,本設計中任務間的數據傳遞被稱為消息),該任務將喪失對CPU的占用權而轉為等待態,等待時間可由系統設定。若等待時間內該任務收到消息,任務將轉為就緒態,否則將被時間管理函數強行轉為就緒態。
中斷發生時運行態的任務將轉入中斷態,喪失對CPU的占用權。因為斷中可能有消息發送使等待態的任務轉入就緒態,故中斷返回后將首先運行調度函數,決定任務狀態。
3.3 任務的構成
系統中每個任務均有以下三部分組成:應用程序、任務堆棧以及任務控制塊。其中只有應用程序被燒入ROM,而任務本身則置于ROM,待系統運行時再予于建立。
任務堆棧以存儲CPU寄存器內容。當某任務由運行態變為其它狀態時,CPU寄存器內容壓入相應任務堆棧,反之則將相應任務堆棧內容置入CPU寄存器。
作為系統中定義中一個數據結構,任務控制塊的內容包括任務堆棧的地址、任務當前狀態、任務優先權等。操作系統通過查詢任務控制塊內容實現對任務的管理。
3.4監視任務的設計
因系統工作環境干擾強烈,雖已采取多種軟硬件抗干擾措施如光電隔離、軟件陷阱等,仍有可能因瞬間擾動使系統陷入混亂,導致 系統只能依靠看門狗復位重新運行,以致無法實現設計目標。為此本系統采用監視任務監督其它任務是否正常運行,若未能正常運行則采取相應措施以盡量減少看門狗復位次數。
監視任務設計思路為:被監視任務正常運行時其執行時間是可預估的,被監視任務在其即將運行完畢時向監視任務發送消息說明自身運行正常。被監視任務運行時,監視任務處于等待態,等待被監視任務給它發送消息,等待時間被設定為預計的任務正常運行所需的最大時間。若等待時間內監視任務收到消息,則認為發送消息的任務運行正常,依照各任務執行順序的先后下一任務開始運行,監視任務等待下一任務發送的消息。若等待時間已過,監視任務仍未收到消息,則系統的時間管理函數將強行把監視任務為就緒態。因監視任務的優先權是最高的,它將搶占對CPU的控制權并采取相應的糾錯方案。本系統中針對常見故障建立對策庫,并將之置于ROM,以便實現應用中根據故障的具體情況采取相應措施。
現以信號采集任務中常出現的一個擾動為例加以介紹。信號采集任務進行信號采集前者先查詢一個標志位,該標志位顯示焊接是否開始。若該標志位置1表明焊接已經開始,任務開始信號采集,否則任務一直查詢直至該標志位置1。若該位在位置時由于瞬間振動導致未能置位成功以致信號采集任務不斷查詢該標志位,將導致系統混亂。若未采用監視任務,則系統只能依靠看門狗復位。在本設計中由于操作系統的采用,使各任務的關系由傳統的順序機制變成并行機制。監視任務在預定的等待時間仍未收到信號采集任務發送的消息,被時間管理函數置為就緒態,且由于其優先權較信號采集任務高,將獲得CPU的使用權,使信號采集任務重新運行以消除擾動的影響,即刷新看門狗寄存器的值,將信號采集任務置為就緒態,并將信號采集任務的任務堆棧的斷點地址值改為采集任務起始地址后重新將自身置為等待態。
4 操作系統層設計
4.1 任務建立
因任務并未常駐ROM,操作系統的首要功能為建立所有任務,將其初始化并置剛建立的任務為就緒態。
4.2 消息隊列
4.2.1 消息隊列的結構
本設計中將任務間傳送的數據稱為消息。因系統中任務間有多個數據傳送,故采用消息隊列。消息隊列實質是一個由指針組成的循環緩沖區,如圖3所示。
其中osqstart為指向消息隊列起始地址的指針,osqend為消息隊列結束單元的下一地址的指針,osqstart、osqend使消息隊列構成一個循環的緩沖區。osqsize為消息隊列的總單元數,該值的大小視任務的需要而定。osqentry為消息隊列中消息數,其值隨數據存取而改變。
osqin為指向消息隊列存入下一條消息的指針。osqout為指向消息隊列取出下一條消息的指針。系統初始化及osqin、osqout到達osqend時將被調整指向消息隊列起始地址。系統完成消息隊列創建后即開始對其進行初始化,將osqentry置為0,osqin、osqout指向消息隊列起始地址。消息隊列的存取采取先進先出的原則,osqin、osqout隨數據的存取相應改變。
4.2.2 系統中的消息隊列
本系統中共有4個消息隊列,各消息隊列用途分別為:
消息隊列1被信號采集任務用于發送消息給信號處理,監視任務;消息隊列2被信號處理任務用于發送消息給控制運算,監視任務;消息隊列3被控制運行任務用于發送消息給輸出任務,監視任務;消息隊列4被輸出任務用于發送消息給監視任務。
本系統定義數據結構--隊列控制塊業實現對多個消息隊列的管理,每個消息隊列對應一個隊列控制塊。隊列控制埠的內容包括指向消息隊列的指針以及該消息隊列對應的等任務。消息存取采取優先權原則,即消息隊列非空時,該消息隊列對應的隊列中等待任務列表內優先權最高的任務先從消息隊列中取消息。因消息發送可能會導致任務狀態的變化,為維護消息的完整,消息發送中禁止任務切換。
因本系統中對消息的存取采取先入先出以及優先權的原則,故各任務發送消息至消息隊列的順序為:先發送給監視任務的消息,后發送給其它任務的消息。各任務從消息隊列讀取的順序為:監視任務先讀,其它任務后讀。
4.3 系統調度
為保證系統的實時性,系統采用搶占式內核,即優先權高的就緒態任務獲得CPU的占有權,優先權低的就緒態任務對CPU的控制權被搶占,從運行態轉入就緒態。此過程由調度函數完成。調度函數找到就緒態擁有最高優先權的任務,并將其與運行態任務的優先權比較,若就緒態任務的優先權較高則模擬一次中斷,將當前CPU寄存器內容壓入運行態任務堆棧,將就緒態任務堆棧內容置于CPU寄存器。
本系統采用靜態優先權,若就緒態中任務的最高優先權變化,則必有任務從等待態轉化成就緒態。而任務從等待態轉化成就緒態的前提為有消息產生,故調用調度函數時機為任務為消息發送完成以及中斷返回。
4.4 時間管理函數
時間管理函數功能為將等待時間已過的等待態任務置位為就緒態,其實質為時鐘中斷的中斷服務程序。系統運行時將監視任務等待時間置為定時器的延時時間,若被監視任務正常運行,則等待時間內監視任務將從消息隊列收到消息,恢復運行態,將則應下一個任務的等待時間(即監視任務收到下一任務給它發送的消息所需時間)置為定時器延時時間。若被監視任務運行異常,將產生時鐘中斷,強行將監視任務置就緒態,以便它采取相應的糾錯措施。
5 系統運行過程分析
系統運行首要環節為初始化,包括兩部分:第一部分為建立任務,為之分配優先權,將其置為就緒態;第二部分為實現任務間的數據傳遞、建立消息隊列及對應的隊列控制塊初始化消息隊列。
系統初始傾聽各任務即可開始調度運行。剛開始時各任務均處就緒態,此時監視任務優先權最高,最先運行,查詢消息隊列1即信號采集任務有無給它發送消息,因消息隊列1為空,監視任務變為等待態并確定等待時間。此時輸出任務在所有就緒態任務中優先權最高,可以運行,但也因消息隊列2空變為等待態,依此類推。雖信號采集任務優先權最低,但其無需等待別的任務給它發送消息,故信號采集任務得到CPU控制權。若信號采集任務未能正常運行則等待時間過后消息隊列仍這人。時間管理函數將強行置監視任務為就緒態,因監視任務的優先權高將獲得CPU控制權并根據故障情況從對策庫中找出相應解決方案。若信號采集任務正常運行則在等待時間內發送消息至消息隊列1,信號處理任務及監視任務轉為就緒態。因監視任務優先權較高,先從消息隊列1獲取消息以確認信號采集任務運行無誤。查詢消息隊列2即信號處理任務有無給它發送消息,因信號處理任務尚未運行,消息隊列2為空,監視任務退出運行態轉入等待態并確定等待時間,信號處理任務獲得對CPU控制權,讀消息并開始運行。其余任務的運行依此類似。當所有任務均運行一次后所有任務狀態為就緒態,開始下一周期的運行。
經系統實際運行證明,因實時嵌入式操作系統uC/OS-II以及監視任務的采用,較好地提高了系統安全性能,有效地減少了復位次數,達到了系統設計目標。