基于μC/OSⅡ的實時任務模型設計
本文通過研究實時操作系統(tǒng)內核及應用技術,分析實時操作系統(tǒng)性能指標;基于實時操作系統(tǒng)μC/OS Ⅱ內核接口和任務運行原理,提取實時任務的構成要素,構建實時任務模型。運用任務模型進行實時任務、實時應用程序的設計和實現。根據任務模型設計實現一個范例程序的基本功能和性能需求;將模型設計思想應用于實時軟件開發(fā),任務模型為實時程序研發(fā)和相關教學活動提供了一個簡便的解決方案。
本文引用地址:http://www.biyoush.com/article/149935.htm1 實時軟件技術及實時軟件構成
實時軟件開發(fā)環(huán)境一般采用實時操作系統(tǒng)(RTOS)作為系統(tǒng)開發(fā)和運行支持平臺,支持模塊化開發(fā),提高開發(fā)效率,縮短開發(fā)周期,便于程序的調試、維護,使實時性能得到保證,系統(tǒng)穩(wěn)定可靠。RTOS為每個任務建立一個可執(zhí)行環(huán)境,并可方便地在任務間傳遞消息,在中斷處理程序和任務間傳遞事件,根據任務優(yōu)先級實施搶占調度。
從實時操作系統(tǒng)(Real-time OS)的內核功能、實現方法和運行機制可得其目標包括:按照搶占優(yōu)先級策略控制管理實時應用程序每個并發(fā)任務的運行;每個任務在多長時限可以完成或得到響應。任務時限(dead-line)是實現每個實時任務必備的性能指標。
時限可以分為硬時限(Hard Deadline)和軟時限(Soft Deadline)。具有硬截止時間的任務即為關鍵任務,如果不能滿足時限,則視為系統(tǒng)錯誤。根據任務設置的重要程度,將擁有關鍵任務的實時系統(tǒng)稱為硬實時系統(tǒng),否則稱為軟實時系統(tǒng)。
1.1 中斷延遲
從一個外部事件發(fā)生到響應中斷處理函數的第一條指令開始執(zhí)行,這段時長稱為中斷延遲。很多實時任務由中斷驅動執(zhí)行,中斷事件必須在限定的時限內處理,否則將產生嚴重后果。
1.2 搶占延遲
從一個外部事件發(fā)生到處理該事件任務的第一條指令開始執(zhí)行,這段時長稱為搶占延遲。大多數實時系統(tǒng)都是處理一些周期性或非周期性的重復事件,事件觸發(fā)任務執(zhí)行。每當事件發(fā)生,相應的處理任務必須及時得到調度執(zhí)行,否則將無法滿足時限。搶占延遲反映系統(tǒng)響應的及時程度。
圖1表示實時軟件設計編程和運行層次結構。該圖對實現實時應用程序功能設計接口和運行機制進行層次劃分。指明基于操作系統(tǒng)內核進行應用開發(fā)的編程層次和接口。從而形成實時應用程序內部結構。
實現具體實時應用業(yè)務邏輯一般采用分解任務的方法。將一個實時應用功能劃分為多個并發(fā)執(zhí)行的任務。分配任務不同的優(yōu)先級,賦予任務自主延遲功能,進行必要的任務通信,設置關鍵任務的中斷響應。調用RTOS內核系統(tǒng)函數接口,創(chuàng)建實時任務;任務的運行從接受內核調度開始,按照自身流程設計循環(huán)執(zhí)行,直至系統(tǒng)運行結束。
實時應用的基本構成單位和基本功能實現方法,如圖2所示。
2 基于μC/OSⅡ內核的實時任務模型
μC/OSⅡ嵌入式操作系統(tǒng)是一個多任務、優(yōu)先級搶占、可移植、可裁減的實時內核。具有時間、內存、信號量、郵箱和信息隊列等各類功能函數,各任務間可以互相通訊,適用于小型CPU,開源代碼簡練,應用領域廣泛。
基于μC/OSⅡ實時操作系統(tǒng)內核進行應用程序開發(fā),首要的工作在于如何將應用程序中的功能進行模塊分解,使每個模塊轉換為可并發(fā)執(zhí)行的任務;調用內核完成任務流程的設計與實現;啟動操作系統(tǒng)內核的任務調度程序,并發(fā)執(zhí)行任務。
實時應用程序的開發(fā)既要考慮內核功能及接口,也要設計應用邏輯功能。設計一個任務模型,直接服務于實時應用程序的設計與實現。該模型對設計與實現的全過程進行簡要分解,對各個環(huán)節(jié)進行功能設計與實現,引導用戶將設計功能轉換為應用程序。
圖3提供了任務模型框架與構建基本步驟。
2.1 任務分解
任務分解將一個實時應用業(yè)務邏輯,按照任務的管理和控制接口劃分為若干獨立的任務,并發(fā)運行,實現應用功能。簡單地分為設計階段和編碼階段。
2.1.1 設計階段
(1)根據應用程序功能需求,將應用程序功能劃分為若干并發(fā)任務。首先將需要并發(fā)執(zhí)行的子功能確立為任務,任務優(yōu)先級按響應的迫切程度確定。
(2)確定每個任務處理流程,確保完成任務功能。
(3)確定任務功能實現是否與其他任務的執(zhí)行有關聯(lián)。
2.1.2 編碼階段
(1)完成每個任務的程序設計。將任務流程使用C語言編寫為獨立的函數。根據應用需求,不同的任務也可共用同一個函數的代碼段。
(2)實時任務需確定優(yōu)先級。為確保低優(yōu)先級任務有機會運行,每個任務函數中需包括睡眠、掛起、等待指定時間等一些自主放棄CPU的語句,調用內核函數實現。
2.2 任務通信
實時任務間存在互相合作或競爭關系。μC/OSⅡ實時操作系統(tǒng)內核允許并發(fā)任務間通過事件、信號量、消息郵箱、消息隊列進行通信。實現分為兩步:定義通信事件數據類型及初始化;任務編碼中適時調用發(fā)送和接收函數。
(1)創(chuàng)建任務前,調用內核,定義需要的通信機制數據結構。
(2)發(fā)送任務和接收任務調用內核任務通信函數實現編碼,發(fā)送任務和接收任務可有多個。
2.3 任務創(chuàng)建
將編碼完成的任務函數,通過調用內核函數,轉換為內核可調度的任務。系統(tǒng)函數INT8U OSTa-skCreate(void(*task)(void*pd),void*pdata,OSSTK*ptos,INT8U prio)的輸人數據為:任務代碼指針——任務函數名;創(chuàng)建任務運行時傳遞的指針——可為空值;任務堆棧棧頂指針——任務現場數據;任務優(yōu)先級——確定任務關鍵程度。
2.4 任務性能
為確保實時應用程序的實時特性,滿足實時軟件的性能需求,必須要求實時內核能夠控制每個實時任務的響應時間和執(zhí)行時間。
任務執(zhí)行時間的測定方法類似。在任務執(zhí)行代碼起始位置開啟定時器;在一個任務周期結束時停止計時。反復調試,測得的最大值計為任務的執(zhí)行時間,又為一個任務最長的一個執(zhí)行周期,也為控制單個任務功能的執(zhí)行提供依據。
2.5 任務與μC/OSⅡ實時內核連接
實時應用程序主函數是整個應用程序的執(zhí)行入口。該函數將應用代碼和操作系統(tǒng)內核代碼進行連接,形成一個完整的應用代碼。主函數一般由以下步驟組成,μc/oSⅡ內核均提供系統(tǒng)函數支持。
(1)初始化μC/OSⅡ操作系統(tǒng)內核;
(2)保存DOS環(huán)境;
(3)安裝μC/OSⅡ中斷等環(huán)境參數;
(4)根據需要創(chuàng)建信號量集;
(5)創(chuàng)建多個應用程序任務;
(6)啟動多任務管理(任務調度程序)運行。
3 μC/oSⅡ實時任務模型的應用
交通信號燈控制系統(tǒng)是一個常見的實時應用系統(tǒng)。該系統(tǒng)根據時間控制十字路口信號燈的自動轉換,其基本功能具有實時系統(tǒng)的基本特點。應用實時任務模型進行該系統(tǒng)的設計與實現。
3.1 系統(tǒng)功能、任務分解、任務通信
(1)應用程序功能說明
十字路口交通信號燈控制十字路口的車輛通過或停止。篇幅所限,控制方式簡述如下:東西向綠燈亮時,南北向紅燈亮,反之亦然,車輛按同方向燈控制通過。
(2)任務分解說明
設置兩個任務分別表示東西向燈task_ew和南北向燈task_ sn。東西向燈任務功能:申請南北向燈任務的同步信號量s_ sn,顯示綠燈指定時間,設定顯示紅燈指定時間,向南北任務發(fā)送同步信號量;南北向燈任務功能:申請東西向燈任務的同步信號量s_ew,顯示綠燈指定時間,設定顯示紅燈指定時間,向東西向任務發(fā)送同步信號量;兩個任務通過兩個信號量保持同步切換機制。
(3)任務間通信
根據任務分解得知,創(chuàng)建兩個信號量,南北向燈信號量s_sn,初值=1;東西向燈信號量s_ew,初值=O。這樣,通過任務代碼申請信號量的順序,可以將十字路口信號燈控制為如下順序和變化周期:東西向信號燈綠燈一東西向信號燈紅燈一南北向信號燈綠燈一南北向信號燈紅燈。
(4)任務代碼
東西向燈任務代碼task_ew()簡要流程如下,以下代碼為無限循環(huán)代碼。
①調用內核系統(tǒng)函數申請南北向燈信號量;
②東西向顯示綠燈,南北向顯示紅燈;
③調用內核函數,任務睡眠指定時間;
④調用內核系統(tǒng)函數發(fā)送東西向燈信號量。
南北向燈任務代碼task_sn()簡要流程如下:以下代碼為無限循環(huán)代碼。
①調用內核系統(tǒng)函數申請東西向燈信號量;
②南北向顯示綠燈,東西向顯示紅燈;
③調用內核函數,任務睡眠指定時間;
④調用內核系統(tǒng)函數發(fā)送南北向燈信號量。
3.2 任務創(chuàng)建
(1)任務函數代碼編碼完成后,調用系統(tǒng)函數0S-TaskCreate()創(chuàng)建任務task_sn和task_ew。
(2)每個應用任務的優(yōu)先級不同,為了使任務按照設定的時間進行紅綠燈顯示切換,每個任務自動設定睡眠若干時間,任務在睡眠狀態(tài)下顯示狀態(tài)保持不變。
3.3 任務與uC/OSⅡ實時內核連接
應用程序主函數的主要流程設計如下:
3.4 實時任務性能指標
若該應用系統(tǒng)具有信號燈自動控制改為手動控制,再由手動改為自動控制功能,需要進行如下設計:
(1)中斷延遲
設置一個實時任務代表手動控制狀態(tài)。當按下按鍵時產生中斷,中斷事件必須在時限內處理,睡眠上述兩個紅綠燈任務,將執(zhí)行切換到手動實時任務。當需要切換到自動狀態(tài)時,按下對應按鍵時產生中斷,處理該中斷,睡眠手動實時任務,喚醒兩個紅綠燈任務。
(2)搶占延遲
有時根據交通流量變化,需要調整十字路口雙方向紅綠燈的切換時間。設置一個時間調整任務,該任務優(yōu)先級較高,可根據每星期各天、各時段路口情況進行周期性動態(tài)時間調整。按指定時間觸發(fā)事件,調度該任務執(zhí)行。搶占延遲就反映了系統(tǒng)的響應及時程度。
提出的根據實時任務模型構建實時應用程序的方法,為基于嵌入式實時內核μC/OSⅡ構建應用程序,提供了一個簡明、方便的技術思路和實現方法,該模型為實時應用程序開發(fā)提供一個實用解決方案。
評論