引 言

　　在嵌入式操作系統領域，由Jean J. Labrosse開發的μC/OS，由于開放源代碼和強大而穩定的功能，曾經一度在嵌入式系統領域引起強烈反響。而其本人也早已成為了嵌入式系統會議（美國）的顧問委員會的成員。

　　不管是對于初學者，還是有經驗的工程師，μC/OS開放源代碼的方式使其不但知其然，還知其所以然。通過對于系統內部結構的深入了解，能更加方便地進行開發和調試；并且在這種條件下，完全可以按照設計要求進行合理的裁減、擴充、配置和移植。通常，購買RTOS往往需要一大筆資金，使得一般的學習者望而卻步；而μC/OS對于學校研究完全免費，只有在應用于盈利項目時才需要支付少量的版權費，特別適合一般使用者的學習、研究和開發。自1992第1版問世以來，已有成千上萬的開發者把它成功地應用于各種系統，安全性和穩定性已經得到認證，現已經通過美國FAA認證。

  
　　1 μC/OS-II的幾大組成部分

　　μC/OS-II可以大致分成核心、任務處理、時間處理、任務同步與通信，CPU的移植等5個部分。

　　核心部分(OSCore.c) 是操作系統的處理核心，包括操作系統初始化、操作系統運行、中斷進出的前導、時鐘節拍、任務調度、事件處理等多部分。能夠維持系統基本工作的部分都在這里。

　　任務處理部分(OSTask.c) 任務處理部分中的內容都是與任務的操作密切相關的。包括任務的建立、刪除、掛起、恢復等等。因為μC/OS-II是以任務為基本單位調度的，所以這部分內容也相當重要。

　　時鐘部分(OSTime.c) μC/OS-II中的小時鐘單位是timetick（時鐘節拍）。任務延時等操作是在這里完成的。

　　任務同步和通信部分 為事件處理部分，包括信號量、郵箱、郵箱隊列、事件標志等部分；主要用于任務間的互相聯系和對臨界資源的訪問。

　　與CPU的接口部分 是指μC/OS-II針對所使用的CPU的移植部分。由于μC/OS-II是一個通用性的操作系統，所以對于關鍵問題上的實現，還是需要根據具體CPU的具體內容和要求作相應的移植。這部分內容由于牽涉到SP等系統指針，所以通常用匯編語言編寫。主要包括中斷級任務切換的底層實現、任務級任務切換的底層實現、時鐘節拍的產生和處理、中斷的相關處理部分等內容。

　　2 對于MSP430的中斷處理

    2.1 函數調用和中斷調用的操作

　　MSP430常使用的C編譯器應該就是IAR Embedd-ed WorkBench。對于這一編譯器來說，通過分析和研究，發現它有以下規律。

    (1)函數調用

　　如果是函數級調用，編譯器會在函數調用時先把當前函數PC壓棧，然后調用函數，PC值改變。

如果被調用的函數帶有參數，那么，編譯器按照以下的規則進行。

　　左邊的兩個參數如果不是struct（結構體）或者union（聯合體），將被賦值到寄存器，否則將被壓棧。函數剩下的參數都將被壓棧。根據左邊的那兩個參數的類型，分別賦值給R12（對于32位類型賦值給R12:R13）和R14(對于32位類型賦值給R14:R15)。

    (2)中斷調用

　　如果是在中斷中調用中斷服務子程序的話，編譯器將把當前執行語句的PC壓棧，同時再把SR壓棧。接著，根據中斷服務子程序的復雜程度，選擇把R12~R15中的寄存器壓棧。然后，執行中斷服務子程序。中斷處理結束后再把Rx寄存器出棧，SR出棧，PC出棧。把系統恢復到中斷前的狀態，使程序接著被中斷的部分繼續運行。

    2.2 任務級和中斷級的任務切換步驟和原理

(1)任務級的任務切換原理

　　 μC/OS-II是一個多任務的操作系統，在沒有用戶自己定義的中斷情況下，任務間的切換步驟是這樣的：任務間的切換一般會調用OSSched()函數。函數的結構如下：

void OSSched(void){

關中斷

如果（不是中斷嵌套并且系統可以被調度）{

確定優先級的任務

如果（的任務不是當前的任務）{

調用OSCtxSw();

}

}

開中斷

}

　　我們把這個函數稱作任務調度的前導函數。它先判斷要進行任務切換的條件，如果條件允許進行任務調度，則調用OSCtxSw()。這個函數是真正實現任務調度的函數。由于期間要對堆棧進行操作，所以OSCtxSw()一般用匯編語言寫成。它將正在運行的任務的CPU的SR寄存器推入堆棧，然后把R4~R15壓棧。接著把當前的SP保存在TCB->OSTCBStkPtr中，然后把優先級的TCB->OSTCBStkPtr的值賦值給SP。這時候，SP就已經指到優先級任務的任務堆棧了。然后進行出棧工作，把R15~R4出棧。接著使用RETI返回，這樣就把SR和PC出棧了。簡單地說，μC/OS-II切換到優先級的任務，只是恢復優先級任務所有的寄存器并運行中斷返回指令（RETI），實際上，所作的只是人為地模仿了一次中斷。

    (2)中斷級的任務切換原理

　　μC/OS-II的中斷服務子程序和一般前后臺的操作有少許不同，往往需要這樣操作：

保存全部CPU寄存器

調用OSIntEnter()或OSIntNesting++

開放中斷

執行用戶代碼

關閉中斷

調用OSIntExit();

恢復所有CPU寄存器

RETI

　　OSIntEnter()就是將全局變量OSIntNesting加1。OSIntNesting是中斷嵌套層數的變量。μC/OS-II通過它確保在中斷嵌套的時候，不進行任務調度。執行完用戶的代碼后，μC/OS-II調用OSIntExit()，一個與OSSched()很像的函數。在這個函數中，系統首先把OSIntNesting減1，然后判斷是否中斷嵌套。如果不是的話，并且當前任務不是優先級的任務，那么找到優先級的任務，執行OSIntCtxSw()這一出中斷任務切換函數。因為，在這之前已經做好了壓棧工作；在這個函數中，要進行R15~R4的出棧工作。而且，由于在之前調用函數的時候，可能已經有一些寄存器被壓入了堆棧。所以要進行堆棧指針的調整，使得能夠從正確的位置出棧。

　　3 使用μC/OS-II存在的問題和解決方法

　　由于μC/OS-II在應用的時候會占用單片機上的一些資源，如系統時鐘、RAM、Flash或者ROM，從而減少了用戶程序對資源的利用。對于MSP430來說，RAM的占用是特別突出的問題。對于8、16位的單片機來說，片內的RAM容量都很小，MSP430也是如此（的片內RAM也只有2KB，例如MSP430F149）。如果使用擴展內存，會大大增加設計難度。

　　通過對μC/OS-II的分析可以得知，μC/OS-II占用的RAM主要是用在每個任務的TCB、每個任務的堆棧等方面。通過進一步分析，發現任務堆棧大的原因是因為MSP430的硬件設計中沒有把中斷堆棧和任務堆棧分開。這樣就造成了在應用μC/OS-II的時候，考慮每個任務的任務堆棧大小時，不單單需要計算任務中局部變量和函數嵌套層數，還需要考慮中斷的嵌套層數。因為，對于μC/OS-II原始的中斷處理的設計、中斷處理過程中的中斷嵌套中所需要壓棧的寄存器大小和局部變量的內存大小，都需要算在每個任務的任務堆棧中，則對于每一個任務都需要預留這一部分內存，所以大量的RAM被浪費。從這里可以看出，解決這一問題的直接方法就是把中斷堆棧和每個任務自己的堆棧分開。這樣，在計算每個任務堆棧的時候，就不需要把中斷處理中（包括中斷嵌套過程中）的內存的占用計算到每個任務的任務堆棧中，只需要計算每個任務本身需要的內存大小，從而提高了RAM的利用率，可以緩解內存緊張的問題。

　　在這種設計方案中，中斷堆棧區也就是利用原有的MSP430中的系統堆棧區。在前后臺的設計形式中，中斷中的壓棧和出棧的操作都是在系統的堆棧區完成的。基于μC/OS-II的任務切換的原理，我們對于任務堆棧的功能和系統堆棧的功能做了以下劃分：任務在運行過程中產生中斷和任務切換的時候，PC和SR以及寄存器Rx都保存在各個任務自己的任務堆棧中；而中斷嵌套產生的壓棧和出棧的操作都是放在系統堆棧中進行的。這種劃分方式是基于盡量將中斷任務與普通任務分開的思想設計的。

　　從前面對于IAR EW的默認操作分析來看，堆棧的結構可以有兩種。一種是把μC/OS-II的任務堆棧設計成圖1所示的形式。這種方法是把編譯器默認的壓棧操作放在前面，然后再把剩下的寄存器進棧。但是，由于編譯器在處理復雜程度不同的中斷服務程序的時候，壓入棧的寄存器的數量不定，所以會對以后其余寄存器的壓棧和出棧操作增加復雜度。這里，我們采用了圖2所示的方式生成堆棧。在這種堆棧中，PC和SR壓棧后，通過調整SP指針，使得R4~R15寄存器覆蓋編譯器默認壓棧的寄存器。這樣，處理的難度會小一點。

　　對于這樣的設計方式，CPU必須能夠：

◆ 有相應的CPU寄存器能夠模仿SP的一些功能，能使用相應的指令來完成類似SP的一些操作；

◆ 作為SP使用的寄存器在編譯過程中不被編譯器默認使用。在IAR的編譯器中，有一個選項可以避免在編譯過程中使用到R4、R5。

　　這兩點MSP430都可以做到。

　　 下面對一個正在運行的優先級為6的任務中斷后，會發生的幾種情況進行分析。

　　 1）在中斷的處理過程中沒有更高優先級的中斷產生，即不會產生中斷嵌套。

　　圖3所示為中斷發生后對于任務優先級為6的任務堆棧所進行的操作。中斷發生后，PC和SR被系統壓棧②，對于IAR C編譯器來說，會按照復雜度不同的中斷服務程序的要求，默認地進行一些寄存器的壓棧操作③。因為我們要求的堆棧格式是如圖2所示的，我們要把SP調整到SR后面④，然后進行R4~R15的壓棧操作，形成我們所要求的堆棧格式⑤。

　　進行任務堆棧的壓棧工作以后，就可以調整SP的指針到系統堆棧了，如圖4所示。壓棧后的SP指向一個壓棧內容①。我們把SP的值賦值給優先級6任務的TCB->OSTCBStkPtr，以便進行任務調度的時候出棧使用②。接著，就把SP調整到系統堆棧處③。在中斷處理過程中，可能會出現壓棧的操作，那么這種情況下SP的指針會隨之移動。由于現在是中斷堆棧中，所以不會破壞任務堆棧的格式。

　　由于沒有中斷嵌套，在中斷處理中沒有別的中斷發生，那么返回的步驟和上述的進棧操作正好相反。在中斷處理完了以后，SP會自動回到圖4中③的SP位置。接著，系統會查詢到優先級的任務，然后把SP的指針移到優先級的任務的任務堆棧，進行R15~R4的出棧工作，用RETI中斷返回指令返回到新的任務。因為我們把所有的任務堆棧都規定成相同的格式，所以它們之間不會產生問題。這里需要注意的是，因為系統在C編譯器的中斷處理中會對中斷進入時默認壓棧的寄存器出棧，所以在設計出棧的程序時，要先把這些內容壓棧，這樣才能正確出棧。

　　2）在中斷的處理過程中，有別的中斷產生，產生中斷嵌套。

　　如圖5所示，由于在處理中斷的時候，SP已經被移到系統堆棧去了，只有當中斷退出的時候才可能把SP移到別的任務的任務堆棧中。所以在中斷的時候進行中斷嵌套，那么對于中斷的處理和次是一樣的，所不同的是，這次保存在堆棧中的不是任務運行中的寄存器，而是中斷處理中的寄存器，而且是保存在系統堆棧中而不是任務堆棧中。從這里就可以看出優化內存的效果。所有的中斷嵌套中的寄存器壓棧都壓在系統堆棧中，這樣對于任務堆棧內存大小的要求大大降低。

　　因為μC/OS-II在進入中斷中，會把全局變量OSIntNesting++；在退出中斷的時候，又會把OSIntNesting--。在退出中斷進行任務切換之前，μC/OS-II會先判斷OSIntNesting是否為0，是0才會進行任務調度。當第二中斷運行結束以后，退出中斷嵌套的時候，OSIntNesting不為0，也就不會進行任務調度。因此，仍舊在系統堆棧出棧，那么系統會繼續前面沒有完成的中斷服務程序。

　　接著退出中斷的順序和非中斷嵌套的順序是一樣的。在中斷處理完以后，SP會自動回到圖4中③的SP位置。接著，系統會查詢到優先級的任務，然后把SP的指針移到優先級的任務的任務堆棧。進行R15~R4的出棧工作，用RETI中斷返回指令返回到新的任務。

　　中斷的情況基本上就是上述兩種。對于有些文獻中提到的在中斷中會調度到更高優先級的任務的情況，筆者覺得是不應該發生的。因為從上面的分析可以看出，默認的（μC/OS-II的設計思路）中斷處理會同時對全局變量OSIntNesting進行增減處理，以給出是否需要任務調度的條件。那么即使在中斷服務程序中把更高優先級的任務就緒，也會等到中斷退出以后再進行調度，除非是在中斷中直接調用更高優先級的任務函數。但這種方法應該是和μC/OS-II的原則相違背的，沿用的是以前前后臺設計的思路。

　　對于這樣的設計方式，時鐘節拍的處理方式必須和一般的中斷處理方式是一樣的。一般來說，MSP430使用WATCHDOG時鐘中斷作為時鐘節拍的產生源。從本質上來說，時鐘節拍本身也是中斷處理過程，所以對于時鐘節拍的處理應該和其它的中斷處理過程相同。實際上，在時鐘節拍的處理過程中也可能會存在中斷嵌套的問題。

　　中斷堆棧和任務堆棧分離設計的程序流程如圖6所示。

　　4 幾點建議

　　① 編寫中斷程序的時候，有條件盡量使用匯編語言。因為這樣可以避免一些編譯器自己進行的操作，減少指針調整的次數。

　　② 在用C編寫中斷服務的時候，因為有些功能必須調用匯編的函數才能實現。調用函數時，有些時候壓棧的PC會破壞堆棧的結構。這個時候需要把堆棧進行適當的調整，保證堆棧格式的正確。

　　③ 中斷處理過程中調用OSIntExit()的時候，由于 μC/OS-II的原始設計中SP指針有時是不調整的，所以在OSIntExit()返回了以后，還要判斷一下是否中斷嵌套。因為有的時候是需要切換任務的。