1 引言
當前,嵌入式開發領域對產品的要求越來越多.如通信速率,穩定性,產品功能,可擴展性,可移植性,適應性等。為了適應這些要求,作者對低版本的μC/OS-II做了一些改進。并選擇一款性價比高的微處理器LPC2210作為其運行的硬件平臺。本文論述的高級繼電器保護裝置除可以動態地實現模擬量和開關量的數據采集外,還可以作為web終端通過遠程主機對終端進行控制或訪問。
2 μC/OS-II其內核結構
宏觀的講,μC/OS-Ⅱ大致分成內核結構、任務管理、時間管理、任務之間的通信與同步和CPU的移植等5個部分。由于嵌入式多任務應用功能軟件系統是應用設計的范疇,所以并不包含在內核中。內核保留給上層應用的接口有3個,分別是軟保護、任務間的通信ITC、和設備服務DSR。一個μC/OS-II內核現狀的結構圖如圖1所示。
圖1 μC/OS-Ⅱ內核現狀結構簡圖
3 μC/OS-Ⅱ關鍵算法邏輯
μC/OS-II采用的是可剝奪型內核,它總是執行就緒條件下優先級最高的任務。系統通過兩種方法進行任務調度:一是時鐘節拍或其它硬件中斷到來后,系統會調用函數執行切換任務功能;二是任務主動進入掛起態或等待態,這時系統通過發軟中斷命令或依靠處理器執行陷阱指令來完成任務切換,中斷服務程序或陷阱處理程序的向量地址必須指向函數OSCtxSw()。任務的優先級唯一地標識了任務,即使兩個任務的重要性是相同的,任務間也必須有優先級上的差異,這就意味著高優先級的任務被處理完成之后,必須進入等待態或者掛起態,否則低優先級的任務永遠也不可能執行,從而嚴重暴露出μC/OS-Ⅱ的缺點,甚至造成系統癱瘓。在產品的開發中也不難發現其內核算法存在的一些問題,如內核具體代碼方面的、體系結構方面的、以及移植作者方面的問題,其中最顯著的就是硬實時性和設備驅動框架問題。
3.1硬保護算法的改進
在μC/OS-II操作系統中,臨界區、硬保護和軟保護是幾個緊密聯系的概念,而硬保護算法又與開關中斷、堆棧和局部變量相聯系。從保護的角度考慮,系統的代碼可以劃分為三種運行環境,即任務環境、中斷環境和設備環境。當代碼運行于這三種環境中時,需要的保護有很大的區別。下面將對臨界區及其保護措施中的部分概念作出定義。
定義1:和中斷環境相關的系統保護稱為硬保護(HP,Hard Protect)。
定義2:和設備環境相關的系統保護稱為設備保護(DP , Device Protect)。
定義3:純粹任務之間的保護稱為軟保護(SP,Soft Protect)。
區別使用不同的保護機制對提高系統的中斷能力和穩定性是非常重要的。當系統中大部分功能是與硬件設備進行數據交流時應盡量用軟保護SP和設備保護DP代替硬保護HP,也是提高系統實時反應能力的重要手段。硬保護的方法有三種,在三種硬保護算法的實現方法中。第一種方法只是單純的開關中斷,因此最簡單;但在嵌套調用時通常會出現內層的開中斷代碼干擾外層保護的邏輯。第二種方法借助堆棧功能很好地解決了第一種方法的嵌套問題,但堆棧指針無法確定。第三種方法是在每個硬保護代碼的函數中定義一個局部變量,進入保護前保存狀態,退出保護時恢復狀態。當OS_CRITICAL_METHOD==3時,實現代碼如下:
Void functionx()
{
#if OS_CRITICAL_METHOD==3
OS_CPU_SR cpu_sr;
#endif
??
OS_ENTER_CRITICAL();
?? //需要硬保護的臨界區代碼
OS_EXIT_CRITICAL();
}
3.2調度器算法的改進
眾所周知,μC/OS-II在設計時強調實時性。它采用單一的基于優先級的搶先式調度算法,有效地保證了實時性的要求。其另外一個特點是任務切換帶來的時延窗口很小。在任務的邏輯狀態中,只有就緒態中優先級最高的任務才可以被真正運行。μC/OS-II任務級的調度器是通過函數OSSched()實現的,0ssched()基本上分布在μC/OS-II的各種ITC功能塊中。調度器函數的偽代碼如下:
{
(1)如果鎖定任務切換(配合軟保護),則直接退出。
(2)計算當前優先級任務。
(3)如果當前任務就是最高優先級任務,則直接退出。
(4)將最高優先級任務編號(OSPrioHighRdy)賦給當前任務編號(OSPrioCur)。
(5)讀出最高優先級任務的控制塊數據指針到OSTCBHighRdy指針。
(6)保存當前任務的環境。保存當前任務的sP到OS_TCB結構中的堆棧指針。
(7)讀出最高優先級任務OSTCBHighRdy及其中的SP,設置堆棧,恢復所改任務的環境,并讀出堆棧中保存的PC(程序計數器,任務當前代碼位置)設置好處理器的PC器存器,任務即可開始執行。
}
在任務數據結構0S_TCB描述中只能見到等待、休眠和就緒三個標記值。每個任務具有一個任務控制塊OS_TCB,任務控制塊負責記錄任務執行的環境,包括任務的優先級、堆棧指針和相關事件控制塊指針等。內核將系統中處于就緒態的任務在就緒表中進行標注,通過就緒表中的兩個變量OSRdyGrp和OSRdyTbl[]可快速查找系統中就緒的任務。讓任務進入等待、就緒等狀態等標記任務狀態描述值的功能是分散在其它模塊中完成的,在此需要修OS_TCB中的OSTCBStat字段。如用ITC中的信號量把任務設置到等待態或者把相關任務設置為就緒態等。
為了提高μC/OS-II適應性,在保證其實時性的前提下,對μC/OS-II的任務狀態圖的等待或掛起態分離為阻塞和等待態,以便實現優先級與時間片結合式調度。從而可以從體系結構上避免μC/OS-II存在的不足。如缺乏時間片調度、低優先級的任務很難得到執行、不支持同優先級任務的調度、優先級反轉等問題。改進的任務狀態轉換圖2。
圖2改進的任務狀態轉換圖
3.3任務就緒算法的改進
改進的μC/OS-II可以管理多達255個任務甚至更多,并且提供功能齊全的實時操作服務。實際上,就緒任務表是一個位矩陣。OSRdyTb1矩陣中位的值為0或1,表示對應的prio任務是否就緒。prio的數據位分為兩部分,Y表示縱坐標,x表示橫坐標,和矩陣中的一位對應。OSRdyGrp是縱坐標上就緒任務組的紀錄,只要該組中任何一位代表的任務就緒(非零),Os_RdyGrp縱坐標的對應位就標記為就緒。任務就緒算法和查詢就緒算法如下:
(1)任務就緒算法:根據任務優先級數使任務進入就緒狀態
OSRdyGrp 1=OSMapTbl[prio》》3]; //用Y映射出縱坐標位
OSRdyTb1[prio》》3] 1=OSMapTb1[prio&0x07]; //用X映射出橫坐標位
(2)查詢就緒算法:通過此算法。μC/OS-II可以找出進入就緒態的優先級最高的任務。
y = OSUnMapTbl[OSRdyGrp]; //直接對應出縱坐標
x = OSUnMapTbl[OSRdyTbl[y]]; //直接對應出橫坐標
prio=(y《《3)+x; //算出優先級
由于老版本的μC/OS-II最多只能管理64個任務.分別對應優先級0~63,其中0為最高優先級,63為最低級,系統保留了4個最高優先級的任務和4個最低優先級的任務.實際上用戶可以使用的任務數僅有56個。就緒任務表其實是一個8x8的位矩陣,而且這個矩陣可以簡化為橫縱兩個數組,同時保持了常數運算。對于要求用μC/OS-II管理更多任務的情況,如要管理255個任務,該算法仍然具有意義。改進前和改進后的任務就緒表如圖3。
圖3改進前和改進后的任務就緒表
此時。最低優先級OS_LOWEST_PRIO的定義值可以大于63,但不能大于254。當μC/OS-II初始化的時候。最低優先級OS_LOWEST_PRIO總是被賦給空閑任務idle task。就緒表(readv list)和事件等待表(event wait lists)由一個16x16的矩陣代替。從理論上講.這也是最低優先級OS_LOWEST_PRIO的定義值不能大于254的原因。
3.4軟保護算法
純粹任務之間的保護稱為軟保護(SP,Soft Protect)。在μC/OS-II中,軟保護包括OSSchedLock和OSSchedUnLock兩個函數,用于保護純任務間全局變量的訪問?;舅悸肥墙柚脖Wo遞增(解鎖時遞減)標記變量OSLockNesting,并在任務調度器中判斷此標記變量,以此鎖住任務調度器。
4 改進的μC/OS-II在LPC2210上的移植
移植μC/OS-II到LPC2210上,需編寫與處理器相關的幾個文件:OS_CPU.H、OS_CPU_A.S、OS_CPU_C.C。除了編寫這三個文件之外,還必須編寫目標板的初始化啟動代碼,這是運行任何其它軟件的基礎。μC/OS-II要求所有*.c文件都要包含頭文件includes.h,這樣使得用戶項目中的每個*.c文件不用考慮它實際上需要那些頭文件。使用includes.h的缺點是可能會包含一些不相關的頭文件,也可能會增加每個文件的編澤時間,但卻增強了代碼的可移植性。本移植不使用軟中斷SWI做底層接口,在OS_CPU.H中定義#define OS_CRITICAL_METHOD 3,即采用第三種方式實現開/關中斷。具體用法已在前面作了介紹。
5 結束語
本文針對μC/OS-II的關鍵算法在分析的基礎上進行了改進,并將其應用到了基于ARM7的RISC微處理器LPC2210上。通過實際的調試和在高級繼電器保護裝置中的應用,表明改進方案是可行的。在不損害實時性的前提下,增強了μC/OS-Ⅱ對需求的適應性、執行效率和對任務的管理能力。
本文創新點:(1)通過對μC/OS-Ⅱ的體系結構和關鍵算法的分析,指出了其在應用中存在的不足和改進的方法。(2)增強了μC/OS-II對需求的適應性、執行效率和對任務的管理能力。(3)對EasyARM2200開發板提供的例程做了改進并將其移植到了自己的開發板上,為應用功能的擴展打下了基礎。
責任編輯:gt
-
嵌入式
+關注
關注
5068文章
19020瀏覽量
303314 -
cpu
+關注
關注
68文章
10826瀏覽量
211158 -
微處理器
+關注
關注
11文章
2247瀏覽量
82321
發布評論請先 登錄
相關推薦
評論