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的源代碼和服務函數。

如此，就可以避免不必要的編譯錯誤，也便于開發項目的維護。