基于μC/OSⅡ的實時任務模型研究與應用

　　0 引 言

　　由于實時程序運行機制與傳統程序相比具有獨特性，在實時應用程序開發和相關教學實踐中，如何根據應用需求和系統功能設計，確立實時程序結構，完成代碼的設計與實現則是一個首要的、關鍵的問題。軟件設計者常因缺乏簡易、實用的實時軟件開發基本方法，難以快速建立全面、系統的開發思路和實施步驟。現有實時內核技術及其應用軟件開發資料篇幅較大，技術細節多，學習周期長，可操作性較差，一定程度上影響軟件開發者的工作進度。需要一種簡便易行、行之有效、可操作性強的開發方法，以便為快速全面了解、掌握實時軟件開發流程提供指南。

　　為此，通過分析實時軟件核心技術，結合μC／OsⅡ實時操作系統內核，提出一個實時程序任務模型。依據該模型，確立實時任務功能及處理流程，調用實時內核，確立一個實時應用程序基本結構，實現實時程序運行機制，最終完成一個實時應用軟件的設計與實現，并提供一個簡單范例應用該任務模型。

　　1 實時軟件技術及實時軟件構成

　　實時軟件開發環境一般采用實時操作系統(RTOS)作為系統開發和運行支持平臺，支持模塊化開發，提高開發效率，縮短開發周期，便于程序的調試、維護，使實時性能得到保證，系統穩定可靠。RTOS為每個任務建立一個可執行環境，并可方便地在任務間傳遞消息，在中斷處理程序和任務間傳遞事件，根據任務優先級實施搶占調度。

　　從實時操作系統(Real-time OS)的內核功能、實現方法和運行機制可得其目標包括：按照搶占優先級策略控制管理實時應用程序每個并發任務的運行；每個任務在多長時限可以完成或得到響應。任務時限(dead-line)是實現每個實時任務必備的性能指標。

　　時限可以分為硬時限(Hard Deadline)和軟時限(Soft Deadline)。具有硬截止時間的任務即為關鍵任務，如果不能滿足時限，則視為系統錯誤。根據任務設置的重要程度，將擁有關鍵任務的實時系統稱為硬實時系統，否則稱為軟實時系統。

　　硬實時技術應用廣泛。例如：航空導航、武器控制等應用系統，必須使用實現硬實時技術的操作系統，將計算、存儲、顯示和機電控制系統以嚴格時限組合為一個系統。軟實時系統運行方式與硬實時系統基本相同，區別在于只須滿足統計意義上的實時要求。軟實時系統一般要求滿足時限的概率達到90％。比如，媒體播放系統一般要求1 s播放24幀圖像。如果數據在數據嚴重負載的情況下，不能在1 s內處理24幀，造成播放失真。如果DVD播放正確率達到95％，用戶就能基本滿意。

　　實時應用系統能否滿足實時性能的要求，可從以下指標進行考察。

　　1．1 中斷延遲

　　從一個外部事件發生到響應中斷處理函數的第一條指令開始執行，這段時長稱為中斷延遲。很多實時任務由中斷驅動執行，中斷事件必須在限定的時限內處理，否則將產生嚴重后果。

　　例如，設定烤箱溫度達到300℃時自動切斷電源。從傳感器探測到該極限溫度，到系統進入切斷電源的中斷處理程序，其間系統處理這個時長即為中斷延遲。顯然，這個時長對烤箱設備的使用安全至關重要。

　　1．2 搶占延遲

　　從一個外部事件發生到處理該事件任務的第一條指令開始執行，這段時長稱為搶占延遲。大多數實時系統都是處理一些周期性或非周期性的重復事件，事件觸發任務執行。每當事件發生，相應的處理任務必須及時得到調度執行，否則將無法滿足時限。搶占延遲反映系統響應的及時程度。

　　例如：μC／OSⅡ某實時應用程序有如下功能，按照設定周期，需要運行統計任務對程序運行部分結果進行統計，從時鐘到時，事件發生，到統計任務開始運行這段時間即為搶占延遲，這個時長決定統計結果誤差的大小。

　　圖1表示實時軟件設計編程和運行層次結構。該圖對實現實時應用程序功能設計接口和運行機制進行層次劃分。指明基于操作系統內核進行應用開發的編程層次和接口。從而形成實時應用程序內部結構。

　　實現具體實時應用業務邏輯一般采用分解任務的方法。將一個實時應用功能劃分為多個并發執行的任務。分配任務不同的優先級，賦予任務自主延遲功能，進行必要的任務通信，設置關鍵任務的中斷響應。明確任務的執行條件、中斷條件和掛起條件等因素。每個任務是系統中一個獨立的執行調度單位和資源分配單位。如圖1所示，調用RTOS內核系統函數接口，創建實時任務；任務的運行從接受內核調度開始，按照自身流程設計循環執行，直至系統運行結束。

　　通過對實時應用功能劃分及運行技術分析研究，總結出實時應用的基本構成單位和基本功能實現方法，如圖2所示。

　　2 基于μC／OSⅡ內核的實時任務模型

　　μC／OSⅡ嵌入式操作系統是一個多任務、優先級搶占、可移植、可裁減的實時內核。具有時間、內存、信號量、郵箱和信息隊列等各類功能函數，各任務間可以互相通訊，適用于小型CPU，開源代碼簡練，應用領域廣泛。

　　μC／OSⅡ操作系統以系統函數形式提供各類管理功能，以任務為單位對應用代碼進行管理。應用程序調用系統函數編碼，并進行編譯、鏈接、運行。應用代碼與內核構成一個整體。實時軟件編碼的核心問題在于將應用軟件的具體功能轉化為系統中一個個并發執行的實時任務，接受操作系統內核調度程序的調度和管理，使應用功能最終實現。

　　基于μC／OSⅡ實時操作系統內核進行應用程序開發，首要的工作在于如何將應用程序中的功能進行模塊分解，使每個模塊轉換為可并發執行的任務；調用內核完成任務流程的設計與實現；啟動操作系統內核的任務調度程序，并發執行任務。

　　由于實時應用程序的開發既要考慮內核功能及接口，也要設計應用邏輯功能。設計一個任務模型，直接服務于實時應用程序的設計與實現。該模型對設計與實現的全過程進行簡要分解，對各個環節進行功能設計與實現，引導用戶將設計功能轉換為應用程序。

　　圖3提供了任務模型框架與構建基本步驟。

　　2．1 任務分解

　　任務分解是將一個實時應用業務邏輯，按照任務的管理和控制接口劃分為若干獨立的任務，并發運行，實現應用功能。簡單地分為設計階段和編碼階段。

　　2．1．1 設計階段

　　(1)根據應用程序功能需求，將應用程序功能劃分為若干并發任務。首先將需要并發執行的子功能確立為任務，任務優先級按響應的迫切程度確定。

　　(2)確定每個任務處理流程，確保完成任務功能。

　　(3)確定任務功能實現是否與其他任務的執行有關聯。

　　2．1．2 編碼階段

　　(1)完成每個任務的程序設計。將任務流程使用C語言編寫為獨立的函數。根據應用需求，不同的任務也可共用同一個函數的代碼段。

　　(2)實時任務需確定優先級。為確保低優先級任務有機會運行，每個任務函數中需包括睡眠、掛起、等待指定時間等一些自主放棄CPU的語句，調用內核函數實現。

　　2．2 任務通信

　　實時任務間存在互相合作或競爭關系。μC／OSⅡ實時操作系統內核允許并發任務間通過事件、信號量、消息郵箱、消息隊列進行通信。實現分為兩步：定義通信事件數據類型及初始化；任務編碼中適時調用發送和接收函數。

　　(1)創建任務前，調用內核，定義需要的通信機制數據結構。

　　(2)發送任務和接收任務調用內核任務通信函數實現編碼，發送任務和接收任務可有多個。

　　2．3 任務創建

　　將編碼完成的任務函數，通過調用內核函數，轉換為內核可調度的任務。系統函數INT8U OSTa-skCreate(void(*task)(void*pd)，void*pdata，OSSTK*ptos，INT8U prio)的輸人數據為：任務代碼指針——任務函數名；創建任務運行時傳遞的指針——可為空值；任務堆棧棧頂指針——任務現場數據；任務優先級——確定任務關鍵程度。

　　2．4 任務性能

　　為確保實時應用程序的實時特性，滿足實時軟件的性能需求，必須要求實時內核能夠控制每個實時任務的響應時間和執行時間。

　　任務的響應時間可利用系統內部定時器計算，根據任務的執行順序，在起始任務開啟定時器，在結束任務停止計時，經反復調試，可以測定實時任務的響應時間，一般設為計時最大值，可為確定任務搶占延遲時間提供直接數據。

　　任務執行時間的測定方法類似。在任務執行代碼起始位置開啟定時器；在一個任務周期結束時停止計時。反復調試，測得的最大值計為任務的執行時間，又為一個任務最長的一個執行周期，也為控制單個任務功能的執行提供依據。

　　2．5 任務與μC／OSⅡ實時內核連接

　　實時應用程序主函數是整個應用程序的執行入口。該函數將應用代碼和操作系統內核代碼進行連接，形成一個完整的應用代碼。主函數一般由以下步驟組成，μc／oSⅡ內核均提供系統函數支持。

　　(1)初始化μC／OSⅡ操作系統內核；

　　(2)保存DOS環境；

　　(3)安裝μC／OSⅡ中斷等環境參數；

　　(4)根據需要創建信號量集；

　　(5)創建多個應用程序任務；

　　(6)啟動多任務管理(任務調度程序)運行。

　　3 μC／oSⅡ實時任務模型的應用

　　交通信號燈控制系統是一個常見的實時應用系統。該系統根據時間控制十字路口信號燈的自動轉換，其基本功能具有實時系統的基本特點。應用實時任務模型進行該系統的設計與實現。

　　3．1 系統功能、任務分解、任務通信

　　(1)應用程序功能說明

　　十字路口交通信號燈控制十字路口的車輛通過或停止。篇幅所限，控制方式簡述如下：東西向綠燈亮時，南北向紅燈亮，反之亦然，車輛按同方向燈控制通過。

　　(2)任務分解說明

　　設置兩個任務分別表示東西向燈task_ew和南北向燈task_ sn。東西向燈任務和南北向燈任務優先級不同。東西向燈任務功能：申請南北向燈任務的同步信號量s_ sn，顯示綠燈指定時間，設定顯示紅燈指定時間，向南北任務發送同步信號量；南北向燈任務功能：申請東西向燈任務的同步信號量s_ew，顯示綠燈指定時間，設定顯示紅燈指定時間，向東西向任務發送同步信號量；兩個任務通過兩個信號量保持同步切換機制。

　　(3)任務間通信

　　根據任務分解得知，創建兩個信號量，南北向燈信號量s_sn，初值＝1；東西向燈信號量s_ew，初值＝O。這樣，通過任務代碼申請信號量的順序，可以將十字路口信號燈控制為如下順序和變化周期：東西向信號燈綠燈一東西向信號燈紅燈一南北向信號燈綠燈一南北向信號燈紅燈。

　　(4)任務代碼

　　東西向燈任務代碼task_ew()簡要流程如下，以下代碼為無限循環代碼。

　　①調用內核系統函數申請南北向燈信號量；

　?、跂|西向顯示綠燈，南北向顯示紅燈；

　?、壅{用內核函數，任務睡眠指定時間；

　　④調用內核系統函數發送東西向燈信號量。

　　南北向燈任務代碼task_sn()簡要流程如下：以下代碼為無限循環代碼。

　?、僬{用內核系統函數申請東西向燈信號量；

　?、谀媳毕蝻@示綠燈，東西向顯示紅燈；

　　③調用內核函數，任務睡眠指定時間；

　?、苷{用內核系統函數發送南北向燈信號量。

　　3．2 任務創建

　　(1)任務函數代碼編碼完成后，調用系統函數0S-TaskCreate()創建任務task_sn和task_ew。

　　(2)每個應用任務的優先級不同，為了使任務按照設定的時間進行紅綠燈顯示切換，每個任務自動設定睡眠若干時間，任務在睡眠狀態下顯示狀態保持不變。

　　3．3 任務與uC／OSⅡ實時內核連接

　　應用程序主函數的主要流程設計如下：

　　3．4 實時任務性能指標

　　若該應用系統具有信號燈自動控制改為手動控制，再由手動改為自動控制功能，需要進行如下設計：

　　(1)中斷延遲

　　設置一個實時任務代表手動控制狀態。當按下按鍵時產生中斷，中斷事件必須在時限內處理，睡眠上述兩個紅綠燈任務，將執行切換到手動實時任務。當需要切換到自動狀態時，按下對應按鍵時產生中斷，處理該中斷，睡眠手動實時任務，喚醒兩個紅綠燈任務。這兩個中斷延遲時間對信號燈控制系統是很重要的性能指標，直接影響路口控制方式的切換是否順暢。

　　(2)搶占延遲

　　有時根據交通流量變化，需要調整十字路口雙方向紅綠燈的切換時間。設置一個時間調整任務，該任務優先級較高，可根據每星期各天、各時段路口情況進行周期性動態時間調整。按指定時間觸發事件，調度該任務執行。事件產生的頻度就確定了該任務的執行時限，因此每次事件發生時，相應的處理任務必須及時響應處理，否則不滿足時限要求，路口將陷于無控制狀態。搶占延遲就反映了系統的響應及時程度。

　　4 結 語

　　提出的根據實時任務模型構建實時應用程序的方法，為基于嵌入式實時內核μC／OSⅡ構建應用程序，提供了一個簡明、方便的技術思路和實現方法，該模型為實時應用程序開發提供一個實用解決方案。從應用程序范例的設計實現可得到隨應用系統需求的改變；實時任務可動態進行增刪；模塊可拆卸。該方案已在我校計算機學院的教學實踐中使用，具有較好的可操作性，開拓了軟件開發的新視角。