嵌入式操作系統UC/OSII bc45編譯ucos-II的過程

丁旖 武穎 丁柄文

摘要：嵌入式系統的應用和發展是計算機技術自桌面系統和網絡技術之后，IT產業和IT技術又一 個新的重大進展。而對于規模比較小的系統，UC/OSII 則以實時行強，內核公開，系統穩定，易于學習和開發等特點受到廣大技術人員和嵌入式愛好者的青睞。本文以UC/OSII為例介紹嵌入式uC/OS-II實時操作系統在嵌入式平臺上的移植程序及方法。

關鍵詞：嵌入式；UC/OSII；實時操作系統；開發流程；移植μC/OS-Ⅱ

1 引言

在日常生活等各個領域.當前流行的嵌入式操作系統有linux,wince, UC/OSII 等等。我國正在成為世界電子制造業的重要基地之一，對嵌入式系統技術及相關技術人才存在巨大需求。

2 uC/OS-II的移植程序

將μC/OS-Ⅱ移植到不同的處理器上。所謂移植，就是使一個實時內核能在某個微處理器或微控制器上運行。

要使μC/OS-Ⅱ正常運行，處理器必須滿足以下要求：

1. 處理器的C編譯器能產生可重入代碼。

用C語言就可以打開和關閉中斷。

處理器支持中斷，并且能產生定時中斷(通常在10至100Hz之間)。

處理器支持能夠容納一定量數據(可能是幾千字節)的硬件堆棧。

處理器有將堆棧指針和其它CPU寄存器讀出和存儲到堆?；騼却嬷兄噶?。

像Motorola 6805系列的處理器不能滿足上面的第4條和第5條要求，所以μC/OS-Ⅱ不能在這類處理器上運行。

移植工作包括以下幾個內容：

用#define設置一個常量的值(OS_CPU.H)

聲明10個數據類型(OS_CPU.H)

用#define聲明三個宏(OS_CPU.H)

用C語言編寫六個簡單的函數(OS_CPU_C.C)

編寫四個匯編語言函數(OS_CPU_A.ASM)

一旦代碼移植結束，下一步工作就是測試。

3 UCOS在51單片機的移植

任務函數中帶有形參和局部變量時若使用reentrant關鍵字會引起重入，從C51.PDF 129-131頁的內容知：為了函數重入，形參和局部變量必須保存在堆棧里，由于51硬件堆棧太小，KEIL將根據內存模式在相應內存空間仿真堆棧(生長方向由上向下，與硬件棧相反)。對于大模式編譯，函數返回地址保存在硬件堆棧里，形參和局部變量放在仿真堆棧中，棧指針為?C_XBP，XBPSTACK=1時，起始值在startup.a51中初始化為FFFFH+1。

為了支持重入，重新設計了堆棧結構。增加了保存仿真堆棧指針?C_XBP和堆棧內容的數據結構。相應改變的文件有：OS_CPU_A.ASM、OS_CPU_C.C、OS_CPU.H、YY.C。建議使用統一的固定大小的堆?？臻g，盡管uCOSII原作者把不同任務使用不同空間看成是優點，但為了在51上有效實現任務重入，還是不使用這個優點。

用戶堆?？臻g的大小是可以精確計算出來的。用戶堆棧空間=硬件堆棧空間+仿真堆棧空間。硬件棧占用內部RAM，內部RAM執行效率高，如果堆?？臻g過大，會影響KEIL編譯的程序性能。如果堆?？臻g小，在中斷嵌套和程序調用時會造成系統崩潰。綜合考慮，可把硬件堆?？臻g大小定成了64字節，用戶根據實際情況可以自行設定。仿真堆棧大小取決于形參和局部變量的類型及數量，可以精確算出。因為所有用戶棧使用相同空間大小，所以取占用空間最大的任務函數的空間大小為仿真堆棧空間大小。這樣用戶堆?？臻g大小就唯一確定了?？蓪⒂脩舳褩？臻g大小用宏定義在OS_CFG.H文件中，宏名為MaxStkSize。

51的SP只有8位，無法在64K空間中自由移動，只好采用拷貝全部硬件堆棧內容的笨辦法。51本來就弱，這么一來缺點更明顯了。其實，引入OS必然要付出代價，一般OS要占用CPU10%-20%的負荷能力，需權衡利弊決定。切換頻率決定了CPU的耗費，頻率越高耗費越大，大到一定程度就該換更強的CPU了。我選了50Hz的切換頻率，不高也不低，用戶可以根據需要自行定奪。

4μC/OS-II在嵌入式開發平臺上進行移植的一般方法和技巧

在選定了系統平臺和開發工具之后，進行μC/OS-II的移植工作，一般需要遵循以下的幾個步驟：

深入了解所采用的系統核心

分析所采用的C語言開發工具的特點

編寫移植代碼

進行移植的測試

針對項目的開發平臺，封裝服務函數 （類似80x86版本的PC.C和PC.H）

系統核心

無論項目所采用的系統核心是MCU、DSP、MPU，進行μC/OS-II的移植時，所需要關注的細節都是相近的。

首先，是芯片的中斷處理機制，如何開啟、屏蔽中斷，可否保存前一次中斷狀態等。還有，芯片是否有軟中斷或是陷阱指令，又是如何觸發的。

此外，還需關注系統對于存儲器的使用機制，諸如內存的地址空間，堆棧的增長方向，有無批量壓棧的指令等。

植代碼

在深入了解了系統核心與開發工具的基礎上，真正編寫移植代碼的工作就相對比較簡單了。

μC/OS-II自身的代碼絕大部分都是用ANSI C編寫的，而且代碼的層次結構十分干凈，與平臺相關的移植代碼僅僅存在于OS_CPU_A.ASM、OS_CPU_C.C以及OS_CPU.H這三個文件當中。

在移植的時候，結合前面兩個步驟中已經掌握的信息，基本上按照《嵌入式實時操作系統μC/OS-II》一書的相關章節的指導來做就可以了。

但是，由于系統核心、開發工具的千差萬別，在實際項目中，一般都會有一些處理方法上的不同，需要特別注意。以C6711的移植為例：

※ 中斷的開啟和屏蔽的兩個宏定義為：

#define OS_ENTER_CRITICAL() Disable_int()

#define OS_EXIT_CRITICAL() Enable_int()

Disable_int和Enable_int是用匯編語言編寫的兩個函數。在這里使用了控制狀態寄存器(CSR)的一個特性——CSR中除了控制全局中斷的GIE位之外，還有一個PGIE位，可用于保存之前的GIE狀態。

因此在Disable_int中先將GIE的值寫入PGIE，然后再將GIE寫0，屏蔽中斷。而在Enable_int中則從PGIE讀出值，寫入GIE，從而回復到之前的中斷設置。

這樣，就可以避免使用這兩個宏而意外改變了系統的中斷狀態——此外，也沒有使用堆?；蚓植孔兞?，比原作者推薦的方法要好。※ 任務的切換：

前文說過，C6711中沒有軟中斷機制，所以任務的切換需要用匯編語言自行編寫一個函數_OSCtxSw來實現，并且 #define OS_TASK_SW() OSCtxSw() 在C6711中需要入棧保護的寄存器包括A0-A15、B0-B15、CSR、IER、IRP和AMR，這些再加上當前的程序地址構成一個存儲幀，需要入棧保存。

_OSCtxSw函數中，需要像發生了一次中斷那樣，將上述存儲幀入棧，然后獲取被激活任務的TCB指針，將其存儲幀的內容彈出，從而完成任務切換。

需要特別注意的是，在這里OS_TASK_SW是作為函數調用的，所以如前文所述，調用時的當前程序地址是保存在B3寄存器中的，這也就是任務重新激活時的返回地址。

※ 中斷的編寫：

如前文所述，如果用“interrupt”關鍵字聲明函數，CCS在編譯時，會自動將該函數中使用到的寄存器入棧、出棧保護。但是，這會導致各種中斷發生時，出入棧的內容各不相同。這對于μC/OS-II是會引起嚴重錯誤的。因為μC/OS-II要求中斷發生時的入棧操作使用和發生任務切換時完全一樣的存儲幀結構。

因此，在移植時、基于μC/OS-II進行開發時，都不應當使用“interrupt”關鍵字，而應用如下結構編寫中斷函數：

void OSTickISR (void)

{

DSP_C6x_Save(); // 服務函數，入棧

OSIntEnter();

if (OSIntNesting == 1) // v2.51版本新增加

{

OSTCBCur->OSTCBStkPtr

=(OS_STK*) DSP_C6x_GetCurrentSP(); // 服務函數

} // 獲取當前SP的值

// 允許中斷嵌套 則在此處開中斷

OSTimeTick();

OSIntExit();

DSP_C6x_Resume(); // 服務函數，出棧

}

DSP_C6x_Save 和DSP_C6x_Resume是兩個服務函數，分別完成中斷的出、入棧操作。它們與OS_TASK_SW函數的區別在于：中斷發生時的當前程序地址是自 動保存在IRP寄存器的，應將其作為任務返回地址，而不再是B3。此外DSP_C6x_Resume是一個永遠不會返回的函數，在將所有內容出棧后，它就直接跳轉回到中斷發生前的程序地址處，繼續執行。

進行移植的測試

在編寫完了所有的移植代碼之后，就可以編寫幾個簡單的任務程序進行測試了，大體上可以分三個步驟來進行，相關資料比較詳盡，這里就不多作贅述 了。

封裝服務函數

最后這個步驟，往往是容易被忽視的，但對于保持項目代碼的簡潔、易維護有很重要的意義。

μC/OS-II的原作者強烈建議將源代碼分路徑進行存儲，

5. 結論

μC/OS-II具有免費、簡單、可靠性高、實時性好等優點，但也有缺乏便利 開發環境等缺點，尤其不像商用嵌入式系統那樣得到廣泛使用和持續的研究更新。但開放性又使得開發人員可以自行裁減和添加所需的功能，在許多應用領 域發揮著獨特的作用。當然，是否在單片機系統中嵌入μC/OS-II應視所開發的項目而定，對于一些簡單的、低成本的項目來說，就沒必要使用了。

參考文獻

[1] JEAN J.LABROSSE，邵貝貝譯.

[2] μC/OS－II ―源碼公開的實時嵌入式操作系統. 中國電力出版社

[3] uC／OS-II-源碼公開的實時嵌人式操作系統【M】，邵貝貝譯．中國電力出版社．2001

[4] 忠梅等 ‘ARM 嵌入式處理器結構與應用基礎．北京：北京虢譬航天大學出版社，2002