實時作業系統的使用，能夠簡化嵌入式系統的應用開發，有效地確保穩定性和可靠性，便於維護和二次開發。

，可固化、可剪裁、具有高穩定性和可靠性，除此以外，μC/OS-II的鮮明特點就是原始碼公開，便於移植和維護。

在μC/OS-II官方的主頁上可以查詢到一個比較全面的移植範例列表。但是，在實際的開發專案中，仍然沒有針對專案所採用晶片或開發工具的合適版本。那麼，不妨自己根據需要進行移植。

本文則以在TMS320C6711 DSP上的移植過程為例，分析了μC/OS-II在嵌入式開發平臺上進行移植的一般方法和技巧。μC/OS-II移植的基本步驟

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

● 深入瞭解所採用的系統核心
● 分析所採用的C語言開發工具的特點
● 編寫移植程式碼
● 進行移植的測試
● 針對專案的開發平臺，封裝服務函式
（類似80x86版本的PC.C和PC.H）

系統核心

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

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

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

在本例中，使用的是TMS320C6711 DSP。這是TI公司6000系列中的一款浮點型號，由於其時鐘頻率非常高，且採用了超常指令字（VLIW）結構、類RISC指令集、多級流水等技術，所以運算效能相當強大，在通訊裝置、影象處理、醫療儀器等方面都有著廣泛的應用。

在C6711中，中斷有3種類型，即復位、不可遮蔽中斷（NMI）和可遮蔽中斷（INT4-INT15）。可遮蔽中斷由CSR暫存器控制全域性使能，此外也可用IER暫存器分別置位使能。而在C6711中並沒有軟中斷機制，所以μC/OS-II的任務切換需要編寫一個專門的函式實現。

此外，C6711也沒有專門的中斷返回指令、批量壓棧指令，所以相應的任務切換程式碼均需程式設計完成。由於採用了類RISC核心，C6711的核心結構中，只有A0-A15和B0-B15這兩組32bit的通用暫存器。 

C語言開發工具

無論所使用的系統核心是什麼，C語言開發工具對於μC/OS-II是必不可少的。
最簡單的資訊可以從開發工具的手冊中查詢，比如：C語言各種資料型別分別編譯為多少位元組；是否支援嵌入式彙編，格式要求怎樣；是否支援“interrupt”非標準關鍵字宣告的中斷函式；是否支援彙編程式碼列表(list)功能，等等。

上述的這樣一些特性，會給嵌入式的開發帶來很多便利。TI的C語言開發工具CCS for C6000就包含上述的所有功能。

而在此基礎上，可以進一步地弄清開發工具的一些技術細節，以便進行之後真正的移植工作。

首先，開啟C編譯器的“彙編程式碼列表(list)”功能，這樣編譯器就會為每個C語言原始檔生成其對應的彙編程式碼檔案。

在CCS開發環境中的方法是：在選單“/Project/Build options”的“Feedback”欄中選擇“Interlisting：Opt/C and ASM(-s)”；或者，也可以直接在CCS的C編譯命令列中加上“-s”引數。

然後分別編寫幾個簡單的函式進行編譯，比較C原始碼和編譯生成的彙編程式碼。例如：

void FUNC_TEMP (void)
{
Func_tmp2(); //呼叫任一個函式
}
在CCS中編譯後生成的ASM程式碼為：
.asg B15, SP // 巨集定義
_FUNC_TEMP:
STW B3,*SP--(8) // 入棧
NOP 2
CALL _ Func_tmp2 //-----------
MVKL BACK, B3 // 函式呼叫
MVKH BACK, B3 //-----------
NOP 3 
BACK: LDW *++SP(8),B3 // 出棧
NOP 4
RET B3 // 函式返回
NOP 5

由此可見，在CCS編譯器的規則中，B15暫存器被用作堆疊指標，使用通用存取指令進行棧操作，而且堆疊指標必須以8位元組為單位改變。

此外，B3暫存器被用來儲存函式呼叫時的返回地址，在函式執行之前需要入棧保護，直到函式返回前再出棧。

當然，CCS的C編譯器對於每個通用暫存器都有約定的用途，但對於μC/OS-II的移植來說，瞭解以上資訊就足夠了。

最後，再編寫一個用“interrupt”關鍵字宣告的函式：

interrupt void ISR_TEMP (void)
{
int a;
a=0;
}
生成的ASM程式碼為：
_ISR_TEMP:
STW B4,*SP--(8) // 入棧
NOP 2
ZERO B4 //---------
STW B4,*+SP(4) // a=0
NOP 2 //----------
B IRP // 中斷返回
LDW *++SP(8),B4 // 出棧
NOP 4 

與前一段程式碼相比，對於中斷函式的編譯，有兩點不同：

● 函式的返回地址不再使用B3暫存器，相應地也無需將B3入棧。（IRP暫存器能自動儲存中斷髮生時的程式地址）

● 編譯器會自動統計中斷函式所用到的暫存器，從而在中斷一開始將他們全部入棧保護——例如上述程式段中，只用到了B4暫存器。

編寫移植程式碼

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

μ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的原作者強烈建議將原始碼分路徑進行儲存，例如本文例子中的所有原始碼就應按如下路徑結構儲存：
/uCOS-II
├─SOURCE // 平臺無關程式碼
│ OS_CORE.C
│ ......
└─TI_C6711 // 系統核心
├─CCS // 開發工具
│ OS_CPU.H 
│ OS_CPU_A.ASM
│ OS_CPU_C.C
│
├─ DSP_C6x_Service // 服務函式
│ DSP_C6x_ Service.H
│ DSP_C6x_ Service.ASM 
│
└─ TEST // 具體的開發專案程式碼
OS_CFG.H
INCLUDES.H
TEST.C ......

如上，DSP_C6x_Service中的服務函式，類似於原作者提供的80x86版本中的PC.C和PC.H檔案。在本文的例子中，服務函式則包括了上文提及的中斷相關函式，以及系統初始化函式DSP_C6x_SystemInit()和時鐘初始化函式DSP_C6x_TimerInit()等。
而具體的開發專案程式碼，則可以分別在“/TI_C6711”路徑下新建自己的目錄，就如同移植測試的“TEST”專案，而無需再關注μC/OS-II的原始碼和服務函式。
如此，就可以避免不必要的編譯錯誤，也便於開發專案的維護。

- ------------

關於μC/OS-II系列軟體版權的說明

Micrium 公司產品包括μC/OS-II，μC/GUI，uC/FS，μC/TCP-IP，μC/USB等。Micrium 公司提供嵌入式系統應用方面的產品，並對其軟體擁有智慧財產權。Micrium花費了大量的時間和財力為嵌入式領域提供高質量的軟體產品。所有上述產品都以原始碼的形式提供給客戶，具有極大的適用性。產品不是免費軟體，也不是開放原始碼的軟體，因此，不能免費使用，需要清楚的闡明μC/OS-II和系列的軟體不是開放原始碼的免費軟體，這是和Linux完全不一樣的。

開發和研究者可以通過購買Micrium公司的Jean先生的μC/OS-II的書籍，而得到μC/OS-II原始碼,但是僅可以作為個人和學校學習使用，所有和μC/OS-II直接和間接相關的商業目的行為，必須購買使用μC/OS-II及系列產品的商業授權，包括晶片/單板/系統廠家的任何參考設計，教學裝置和最終的產品，如果沒有得到Micrium公司Jean先生簽字的合法授權都是不合法的使用, 這在μC/OS-II的書籍Micrium公司(

Micrium公司其它軟體如μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等的銷售模式與μC/OS-II不同，如果沒有購買使用授權，完全不可以擁有該原始碼，也不能將原始碼用於產品的設計，培訓，教學和生產。

μC/OS-II, μC/GUI，μC/FS，μC/TCP-IP，μC/USB 等授權方式有：單個產品、產品線（系列）、按照CPU 劃分的產品三種形式，μC/OS-KA，μC/OS-VIEW 等工具是按照使用人的數目收取費用的，相對起傳統的RTOS 動輒2-3萬美圓的開發費用和每塊單板的使用費（根據數量從數百到幾個美圓），μC/OS-II及系列產品是採用一次性的收費方式，應該只是大約相當於傳統RTOS 的10-20% 的總體費用。

如果您正在將μC/OS-II系列軟體用於您的產品，您需要購買並獲得正式使用授權。