一、???????????? 統概述

目前市場上的商用嵌入式系統產品，如Vxwork、PSOS和Windows CE等已經十分成熟，提供有力的開發和調試工具，但開發成本昂貴，而uCOS-II是一種多任務實時操作系統，內核源代碼公開，短小精干，移植性較強，非常適用于一些小型系統開發。本系統描述了如何將uCOS-II移植應用到MCS51系列單片機上，并論述了如何把它實際應用到“嵌入式設備—車載GPS”系統中。

1、? uCOS-II簡介

實時嵌入式操作系統uCOS-II是基于優先級的搶占式實時多任務操作系統，包含了實時內核、任務管理、時間管理、任務間通信同步（信號量，郵箱，消息隊列）和內存管理等功能。絕大部分代碼用C語言寫成，與硬件相關部分用匯編語言編寫，而且它的源代碼是公開免費的。

uCOS-II是面向中小型嵌入式系統的，包含全部功能模塊的內核大約為10K，如果經過裁減只保留核心代碼，則可壓縮到3K左右。RAM的占用量與系統中的任務數有關，任務的堆棧要占用大量的RAM空間，堆棧的大小取決于任務的局部變量、緩沖區大小及可能的中斷嵌套層數。應用程序的時間精度由系統時鐘節拍決定，uCOS-II需要用戶提供周期性的時鐘信號源，用于實現時間延時和確認超時，一般時鐘節拍應在10到100HZ之間（最大精度為10ms），因為uCOS-II在每一個節拍都要檢查有沒有更高優先級的任務在等待執行，若有，就要進行任務切換，所以時鐘節拍率越高，系統的額外負荷就越重。

2、系統的設計目標

本車載移動終端主要完成以下這些控制功能：

（1）位置及相關信息傳送，包括實時請求發送、等時間間隔發送、等距離發送，傳送方式包括GPRS方式和短信方式，由于用GPRS方式進行數據通訊按流量記費，每1K字節2-3分錢，費用相對短信低很多，因此本系統采用GPRS為主，短信為輔的通訊方式。

（2）報警功能，分以下幾部分：

A、特定區域報警功能：設定報警特定區域后（如控制中心規定的行駛任務區域），當車輛駛出設定區域時，監控中心向車載單元報警，并及時記錄車輛的實時位置信息。

B、緊急報警功能：當車輛遇到搶劫、交通事故等緊急情況時，司機可以通過緊急求救按鈕向控制中心發出求救信號，并上傳車輛定位數據。

C、防盜報警功能：當車輛設為防盜狀態時，任何對車輛的非法移動，車載單元會自動報警并上傳車輛定位數據。

D、掉電報警功能：當車載單元主電源掉電（或被人為切斷）時，車載單元會自動報警并上傳車輛定位數據。

E、能自動報警與手動報警相結合：系統支持手動的單鍵報警和智能設備產生的自動報警功能。單鍵人工報警需要司機進行快速隱蔽的單鍵操作快速報警。自動報警如智能非法移動報警，系統自動產生報警信息并發送到監控中心，并保存報警數據，監控中心的人員可以根據需要采取措施。

（3）電源監控功能，實時監控備用電源，如果發現電量不夠，將自動切換到充電模式，直到電量充足后自動切斷充電模式。

3、? 系統的功能塊

系統結構圖如圖1所示，有外向內可分三層：硬件電路層、任務層、操作系統層。

圖1 系統結構圖

二、硬件電路層設計

本系統的移動終端主要包括以下四個部分組成：GPS模塊、GPRS模塊、手柄、單片機控制模塊，其大致功能分述如下：

（1）?????? GPS模塊——用于衛星定位數據的采集，采集時間間隔可設定，最小間隔為1秒采集一次。

（2）?????? GPRS通信模塊——用于實現GPRS數據的收發、短信息收發和語音通話功能。

（3）?????? 手柄——用于語音通話。

（4）?????? 單片機控制模塊——用于控制GPS、GPRS模塊的數據接收、發送、語音通話控制、短信息收發、電源監測管理和對汽車進行控油控電等功能。

三、任務層的設計

1、系統任務層組成及其優先權設置

系統任務層并行存在以下六個任務：監視任務、按鍵處理任務、摘掛機任務、GPRS任務、短消息任務、串口接收任務。每個任務均有以下三部分組成：應用程序、任務堆棧以及任務控制塊。其中只有應用程序被燒入ROM,而任務本身則被置于RAM，待系統運行時再建立。任務堆棧用以存儲CPU寄存器內容。當某任務由運行態變為其它狀態時，CPU寄存器內容壓入相應任務堆棧，反之則將相應任務堆棧內容置入CPU寄存器。作為系統中定義的一個數據結構，任務控制塊的內容包括任務堆棧的地址、任務當前狀態、任務優先權等。操作系統通過查詢任務控制塊內容實現對任務的管理。

優先權的設置由各任務的執行順序以及對系統安全性影響的大小決定，其優先權從高到低依次為：監視任務、按鍵處理任務、摘掛機任務、GPRS任務、短消息任務、串口接收任務。本系統采用靜態優先權設置，即運行過程中任務優先權不變。

2、? 任務的狀態

本系統中各任務的狀態有4種：等待態、就緒態、運行態以及中斷態。狀態的轉換關系如圖2所示。當一個任務占用CPU時該任務處于運行態，其優先權必較所有就緒態任務優先權高。若系統運行導致就緒態某一任務的優先權高于運行態任務優先權，則調用調度函數，運行態任務將喪失對CPU的占用權而轉為就緒態，優先權最高的就緒態任務轉為運行態。某一時刻只能有一個任務處于運行態。任務在就緒態和運行態間的轉化被稱為任務切換。當運行態的任務期待某一消息時（即任務和任務之間的數據傳遞），該任務將喪失對CPU的占用權而轉為等待態，等待時間可由系統設定。若等待時間內該任務收到消息，任務將轉為就緒態，否則將被時間管理函數強行轉為就緒態。中斷發生時運行態的任務將轉入中斷態，喪失對CPU的占用權。因中斷中可能有消息發送使等待態的任務轉入就緒態，故中斷返回后將首先運行任務調度函數，決定任務狀態。

四、軟件層設計

本系統選用μC/OS-II操作系統，將其移植到MCS51系列單片機上。系統采用的時鐘節拍為Tick=50次/秒(即0.02秒/次)，在main中創建所有任務和信號量、消息油箱、消息隊列等。

void main (void)

{
OSInit()；

3、? 摘掛機任務

當拿起聽筒或放下聽筒時，就產生中斷。在中斷中，調用OSSemPost(HookSem)來喚醒摘/掛機任務，同時清除中斷標志。摘掛機任務調用OSSemPend(HookSem,0,&err)來獲得信號量。獲得信號量后，根椐摘掛機狀態標志來判斷是摘機還是掛機。在掛機的時候，如果先前是在響鈴的時候摘機的，那么摘掛機任務把它當做已接來電處理；如果不是在響鈴的時候摘機的，那么在掛機的時候摘掛機任務就把它當做已撥電話處理。

4、? GPRS任務

當讀串口任務接收到GPRS數據時，調用OSQPost(GprsQ,(void *)&Gprs_Buf[0])函數向來喚醒GPRS任務，GPRS任務不斷調用gprs_msg =OSQPend(GprsQ,50,&err)來獲得從讀串口任務中發來的GPRS數據，根據當前的狀態決定是否向控制中心發送定位數據及相關信息。

5、? 短消息處理任務

在GPRS網絡不可用的情況下，系統啟動短消息任務進行數據的通信，當讀串口任務接收到短消息時，調用OSQPost(SMsgQ,(void *)&SMsg_Buf[0])向短信息任務發送消息，短信息任務不斷調用sm_msg =OSQPend(SMsgQ,100,&err)來獲得短消息，然后進行相應的短信收發處理。

6、? 讀串口任務

在讀串口任務中，從接收緩沖區中讀取來自GPRS通訊模塊和GPS模塊發送的字符串，同時分析接收的字符串坐相應的處理以及向GPRS任務和短消息任務發送消息。

結語

本文描述了在MCS51的硬件平臺上實現uC/OS-II，并針對傳統的單片機程序設計方法設計的穩定性不佳的問題，提出了基于uC/OS-II的嵌入式系統設計的方案。但是，使用實時內核來管理這些任務，會增加系統的內存容量和CPU時間的消耗，而且任務調度的優勢不能很好地顯示出來，因此，該設計有一定局限性。但是，在系統的內存足夠大、CPU運行速度足夠快的情況下，使用實時內核uC/OS-II設計，可以提高了系統的可靠性和穩定性，有利于系統的后繼開發，本系統選用CPU為W78E516，外擴32K RAM,晶振頻率為22.1184M，能很好的滿足系統的要求。

//創建信號量、消息隊列；

HookSem = OSSemCreate(0); //喚醒摘掛機任務

GprsQ = OSQCreate(&GprsMsg[0],10);

SMsgQ = OSQCreate(&SMsg[0],5);

//創建內存區域；

Mem20 = OSMemCreate(Part1,20,50,&err);

Mem50 = OSMemCreate(Part2,100,10,&err);

//任務創建；

OSTaskCreate(WatchDogTask,(void*)0,&WatchDogStk[0],2)； //監視任務

OSTaskCreate((void*) KeyTask,(void*)0,&KeyTaskStk[0],3)； //按鍵處理任務

OSTaskCreate((void*)WriteTask,(void*)0,&WriteStk[0],4)； //摘掛機任務

OSTaskCreate((void*)GPRSTask,(void*)0,&GPRSStk[0],5)； //GPRS任務

OSTaskCreate((void*)SMsgTask,(void*)0,&SMsgStk[0],6)； //短信息任務

OSTaskCreate(ReadTask, (void *)0, &ReadStk[0],7)； //讀串口任務

OSStart()；

}

1、監視任務

因本系統工作于干擾強烈的汽車環境中，雖已采取多種硬件抗干擾措施如加屏蔽罩、可靠接地、設置軟件陷阱等，仍有可能因瞬間擾動使系統陷入混亂，導致系統跑飛而只能依靠看門狗復位重新運行，以致無法實現設計目標。為此，本系統采用監視任務監督其它任務是否正常運行，若某一任務未能正常運行則采取相應措施以盡量減少看門狗復位次數。

監視任務設計思路為：被監視任務正常運行時其執行時間是可預估的，被監視任務在其即將運行完畢時向監視任務發送消息說明自身運行正常。被監視任務運行時，監視任務處于等待態，等待被監視任務給它發送消息，等待時間被設定為預計的任務正常運行所需的最大時間。若等待時間內監視任務收到消息，則認為發送消息的任務運行正常，依照各任務執行順序的先后下一任務開始運行，監視任務等待下一任務發送的消息。若等待時間已過，監視任務仍未收到消息，則系統的時間管理函數將強行把監視任務視為就緒態。因監視任務的優先權是最高的，它將搶占對CPU的控制權并采取相應的糾錯方案。

2、? 按鍵處理任務

按鍵處理任務主要對防盜報警、搶車報警、打接電話按鈕進行處理，當任務循環檢測到按鍵按下時，按鍵處理任務發送相應的信號量到處理相應按鍵的程序中。