【正文】 2． 軟件中斷異常 SWI 服務程序 C 語言部分 軟件中斷的 C語言處理函數(shù)代碼見 程序清單 ，其中參數(shù) SWI_Num 為功能號，而 Regs為指向堆棧中保存寄存器的值的位置。 程序清單 軟中斷代碼的 C 語言部分 void SWI_Exception(int SWI_Num, int *Regs) { OS_TCB *ptcb。 (12) case 0x80: __asm (13) { MRS R0,SPSR (14) BIC R0,R0,0x1f (15) ORR R0,R0,SYS32Mode (16) MSR SPSR_c,R0 (17) } break。=~(15)。(33) } } break。這些代碼與處理器有關，是需要移植的代碼。 4． OSStartHighRdy μ C/OSII的啟動多任務環(huán)境的函數(shù)叫做 OSStart()，用戶在調(diào)用 OSStart()之前，必須已經(jīng)建立了一個或更多任務。軟中斷的 1 號功能并沒有在這里實現(xiàn)。 處理器模式轉(zhuǎn)換函數(shù) ChangeToSYSMode()和 ChangeToUSRMode()使用軟件中斷功能0x80 和 0x81 實現(xiàn)，其中函數(shù) ChangeToSYSMode()（程序清單 (13)~(18)）把當前任務轉(zhuǎn)換到系統(tǒng)模式，函數(shù) ChangeToUSRMode()（程序清單 (19)~(24)）把當前任務轉(zhuǎn)換到用戶模式，它們可以在任何情況下使用。為了糾正這個錯誤，本移植增加兩個函數(shù) TaskIsARM()和 TaskIsTHUMB()用于改變?nèi)蝿战r默認的指令集。函數(shù) TaskIsARM()和 TaskIsTHUMB()使用軟件中斷功能 0x82 和 0x83 實現(xiàn)。 6． ? Hook()函數(shù) μ C/OSII 有很多由用戶編寫的? Hook()函數(shù)，它們在本移植中全為空函數(shù)，用戶可以根據(jù)μ C/OSII 的要求修改它。如果是 Thumb 指令集狀態(tài)，則通過 程序清單 (6)讀取指令，通過 程序清單 (7)取得指令中的功能號。這兩個功能不在 C語言中實現(xiàn)，原因一是因為它們需要明確的堆棧結構，這是 C語言不能 提供的；原因二是兩個任務切換程序本身是使用匯編編寫，且同在 這個文件中，使用匯編跳轉(zhuǎn)十分方便。由 小節(jié)可知， OS_TASK_SW()是使用 SWI 軟件中斷的 0 號功能實現(xiàn)的。這樣，如果中斷調(diào)用 OSIntCtxSw()時需要相同的堆棧結構， R3 也要保存著 SPSR，這需要中斷服務程序保證。獲取 PC (1) LDR R12,[SP,16] 。獲取 R0R3 (9) ADD SP,SP,8 。保存 CPSR,OsEnterSum (15) 。保存 R0R3 (12) LDR R1,=OsEnterSum 。保存 LR,PC (6) STMFDSP!,{R4R12} 。 程序清單 OSIntCtxSw 代碼 OSIntCtxSw 。由 程序清單 可知，此時的堆棧結構如圖 所示。 2． OS_TASK_SW()和 OSIntCtxSw() OS_TASK_SW()是在μ C/OSII從低優(yōu)先級任務切換到最高優(yōu)先級任務時被調(diào)用的，OS_TASK_SW()總是在任務級代碼中被調(diào)用的。 然后，程序用功能號與 1 比較（程序清單 (10)），當功能號無符號小于 1 時就是 0 了，就跳轉(zhuǎn)到任務切換函數(shù)處（程序清單 (11)），也就是 OS_TASK_SW()。 程序清單 軟件中斷代碼的匯編部分 SoftwareInterrupt LDR SP, StackSvc (1) STMFD SP!, {R0R3, R12, LR} (2) MOV R1, SP (3) MRS R3, SPSR (4) TST R3, T_bit (5) LDRNEH R0, [LR,2] (6) BICNE R0, R0, 0xff00 (7) LDREQ R0, [LR,4] (8) BICEQ R0, R0,0xFF000000 (9) CMP R0, 1 (10) LDRLO PC, =OSIntCtxSw (11) LDREQ PC, =__OSStartHighRdy (12) BL SWI_Exception (13) LDMFD SP!, {R0R3, R12, PC}^(14) 軟中斷的功能號包含在 SWI 指令中，程序通過讀取該條指令的相應位段獲得。首先，程序判斷傳遞的參數(shù)（任務的優(yōu)先級）是否在允許的范圍內(nèi)（程序清單 (25)、 (30)）。這樣，如果在低優(yōu)先級的任務中創(chuàng)建高優(yōu)先級的任務就十分危險了。 前面已經(jīng)說明：任務可以使用 ARM 的兩種指令集的任意一種運行，但是任務建立時默認的只是一種指令集。 5． 移植增加的特定函數(shù) 根據(jù) ARM 內(nèi)核的特點和移植的目標，為此增加了兩個處理器模式轉(zhuǎn)換函數(shù)（ ChangeToSYSMode() 、 ChangeToUSRMode() ）和兩個任務初始指令集設置函數(shù)（ TaskIsARM()、 TaskIsTHUMB()） 。 程序清單 OSStartHighRdy()代碼 void OS_StartHighRdy(void) { O_SStartHighRdy()。由于使用了軟件中斷，程序狀態(tài)寄存器 CPSR 保存到程序狀態(tài)保存寄存器 SPSR 中，軟件中斷退出時會將 SPSR 恢復到CPSR中，所以程序只要改變程序狀態(tài)保存寄存器 SPSR 中的相應的控制位就可以了。 (35) } } 3. OS_ENTER_CRITICAL() 和 OS_EXIT_CRITICAL() μ C/OSII 使用宏 OS_ENTER_CRITICAL()（ 程序清單 (1)~(6)） 和 OS_EXIT_CRITICAL()（ 程序清單 (7)~(12)） 分別關中斷和開中斷。 (29) case 0x83: if (Regs[0] = OS_LOWEST_PRIO) (30) { ptcb = OSTCBPrioTbl[Regs[0]]。 (24) case 0x82: if (Regs[0] = OS_LOWEST_PRIO) (25) { ptcb = OSTCBPrioTbl[Regs[0]]。 (5) break。對比 表 可知，軟中斷的 0、 1 號功能并沒有在這里實現(xiàn)。每個任務有獨立的 OsEnterSum，在任務切換時保存和恢復各自的 OsEnterSum。 /* 關中斷計數(shù)器 OsEnterSum*/ return (stk)。 /* r2*/ *stk = 0。 /* r6*/ *stk = 0。 /* r10*/ *stk = 0。 /* pc*/ *stk = (OS_STK) task。opt39。根據(jù) 圖 ，很容易寫出函數(shù) OSTaskStkInit()的代碼，具體代碼見 程序清單 。 置 OS_STK_GROWTH 為 1 表示堆棧從上往下長。 /* 任務切換到系統(tǒng) 模式 */ __swi(0x81) void ChangeToUSRMode(void)。 /* 任務級任務切換函數(shù) */ __swi(0x01) void _OSStartHighRdy(void)。同時，這個函數(shù)也可以有參數(shù)和返回值，其傳遞規(guī)則與一般函數(shù)一樣。為了使底層接口函數(shù)與處理器狀態(tài)無關，同時在任務調(diào)用相應的函數(shù)不需要知道函數(shù)位置，本移植使用軟中斷指令 SWI 作為底層接口，使用不同的功能號區(qū)分不同的函數(shù)。 Typedef float FP32。 Typedef unsigned short INT16U。根據(jù) ADS 編譯器的特性，這些代碼如 程序清單 所示。所有的配置改變包括頭文件的增減均在 中進行，而 定下來后不必改動（μ C/OSII 的系統(tǒng)文件需要包含的東西是固定的）。 關于頭文件 和 C/OSII 要求所有 .C 文件的都要包含頭文件 ，這樣使得用戶項目中的每個 .C文件不用分別去考慮它實際上需要哪些頭文件。將 更名為 是遵照編譯器的慣例。 同時支持以上 4 點的 C語言編譯器幾乎不存在，即使存在，移植代碼往往也會使用部分匯編語言來提高移植代碼的效率。其它部分也很重要，它們在細節(jié)上影響代碼，并最終影響代碼的正確性、可靠性和健壯性。關于第 2 點和第 4 點可以參考參考文獻 [9]。 移植 μ C/OSII 概述 要移植一個操作系統(tǒng)到一個特定的 CPU 體系結構上并不是一件很容易的事情，它對移植者有以下要求： 1． 對目標體系結構要有很深了解； 2． 對 OS 原理要有較深入的了解； 3． 對所使用的編譯器要有較深入的了解； 4． 對需要移植的操作系統(tǒng)要有相當?shù)牧私猓? 5． 對具體使用的芯片也要一定的了解。而系統(tǒng)模式除了是特權模式外，其它與用戶模式一樣，因而可選的給任務使用的模式只有用戶模式和系統(tǒng)模式。GCC 雖然支持廣泛，很多開發(fā)套件使用它作為編譯器，與 ADS 比較其編譯效率較低，這對充分發(fā)揮芯片性能很不利，所以最終使用 ADS 編譯程序和調(diào)試。主要包括中斷級任務切換的底層實現(xiàn)、任務級任務切換的底層實現(xiàn)、時鐘節(jié)拍的產(chǎn)生和處理、中斷的相關 處理部分等內(nèi)容。 4) 任務同步和通信部分 為事件處理部分，包括信號量、郵箱、郵箱隊列、事件標志等部分；主要用于任務間的互相聯(lián)系和對臨界資源的訪問。包括任務的建立、刪除、掛起、恢復等等。 C/OSII 的組成部分 μ C/OSII可以大致分成核心、任務處理、時間處理、任務同步與通信， CPU 的移植等 5個部分。 調(diào)度工作的內(nèi)容可以分為兩部分：最高優(yōu)先級任 務的尋找和任務切換。 任務調(diào)度將在以下情況 下發(fā)生： 1） 高優(yōu)先級的任務因為需要某種臨界資源，主動請求掛起，讓出處理器，此時將調(diào)度就緒狀態(tài)的低優(yōu)先級任務獲得執(zhí)行，這種調(diào)度也稱為任務級的上下文切換。 任務調(diào)度 uC/OSII 采用的是可剝奪型實時多任務內(nèi)核。釋放內(nèi)存時將該塊放回它以前所屬的分區(qū)，這樣能有效解決碎片問題，同時執(zhí)行時間也是固定的。但在嵌入式實時系統(tǒng)中，多次 這樣的操作會導致內(nèi)存碎片，且由于內(nèi)存管理算法的原因， malloc和 free 的執(zhí)行時間也是不確定。 時間管理 uC/OSII 的時間管理是通過定時中斷來實現(xiàn)的，該定時中斷一般為 10毫秒或 100毫秒發(fā)生一次，時間頻率取決于用戶對硬件系統(tǒng)的定時器編程來實現(xiàn)。 任務管理 uC/OSII 中最多可以支持 64 個