移植μC/OS-Ⅱ

************************************************************************

*/

typedefunsignedcharBOOLEAN;

typedefunsignedcharINT8U;/* 無符號8位整數(shù) */(1)

typedefsignedcharINT8S;/* 有符號8位整數(shù) */

typedefunsignedinTINT16U;/* 無符號16位整數(shù) */

typedefsignedintINT16S;/* 有符號16位整數(shù) */

typedefunsignedlONgINT32U;/* 無符號32位整數(shù) */

typedefsignedlongINT32S;/* 有符號32位整數(shù) */

typedeffloatFP32;/* 單精度浮點(diǎn)數(shù) */(2)

typedefdoubleFP64;/* 雙精度浮點(diǎn)數(shù) */

typedefunsignedintOS_STK;/* 堆棧入口寬度為16位 */

/*

*************************************************************************

* 與處理器相關(guān)的代碼

*************************************************************************

*/

#defineOS_ENTER_CRITICAL()???/* 禁止中斷 */(3)

#defineOS_EXIT_CRITICAL()???/* 允許中斷 */

#defineOS_STK_GROWTH1/* 定義堆棧的增長方向： 1=向下,0=向上 */(4)

#defineOS_TASK_SW()???(5)

8.03.01與編譯器相關(guān)的數(shù)據(jù)類型

因?yàn)椴煌奈⑻幚砥饔胁煌淖珠L，所以μC/OS-Ⅱ的移植包括了一系列的類型定義以確保其可移植性。尤其是，μC/OS-Ⅱ代碼從不使用C的short,int和long等數(shù)據(jù)類型，因?yàn)樗鼈兪桥c編譯器相關(guān)的，不可移植。相反的，我定義的整型數(shù)據(jù)結(jié)構(gòu)既是可移植的又是直觀的[L8.1(2)]。為了方便，雖然μC/OS-Ⅱ不使用浮點(diǎn)數(shù)據(jù)，但我還是定義了浮點(diǎn)數(shù)據(jù)類型[L8.1(2)]。

例如，INT16U數(shù)據(jù)類型總是代表16位的無符號整數(shù)?，F(xiàn)在，μC/OS-Ⅱ和用戶的應(yīng)用程序就可以估計出聲明為該數(shù)據(jù)類型的變量的數(shù)值范圍是0-65535。 將μC/OS-Ⅱ移植到32位的處理器上也就意味著INT16U實(shí)際被聲明為無符號短整型數(shù)據(jù)結(jié)構(gòu)而不是無符號整型數(shù)據(jù)結(jié)構(gòu)。但是，μC/OS-Ⅱ所處理的仍然是INT16U。

用戶必須將任務(wù)堆棧的數(shù)據(jù)類型告訴給μC/OS-Ⅱ。這個過程是通過為OS_STK聲明正確的C數(shù)據(jù)類型來完成的。如果用戶的處理器上的堆棧成員是32位的，并且用戶的編譯文件指定整型為32位數(shù)，那么就應(yīng)該將OS_STK聲明位無符號整型數(shù)據(jù)類型。所有的任務(wù)堆棧都必須用OS_STK來聲明數(shù)據(jù)類型。用戶所必須要做的就是查看編譯器手冊，并找到對應(yīng)于μC/OS-Ⅱ的標(biāo)準(zhǔn)C數(shù)據(jù)類型。

8.03.02OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()

與所有的實(shí)時內(nèi)核一樣，μC/OS-Ⅱ需要先禁止中斷再訪問代碼的臨界段，并且在訪問完畢后重新允許中斷。這就使得μC/OS-Ⅱ能夠保護(hù)臨界段代碼免受多任務(wù)或中斷服務(wù)例程(ISRs)的破壞。中斷禁止時間是商業(yè)實(shí)時內(nèi)核公司提供的重要指標(biāo)之一，因?yàn)樗鼘⒂绊懙接脩舻南到y(tǒng)對實(shí)時事件的響應(yīng)能力。 雖然μC/OS-Ⅱ盡量使中斷禁止時間達(dá)到最短， 但是μC/OS-Ⅱ的中斷禁止時間還主要依賴于處理器結(jié)構(gòu)和編譯器產(chǎn)生的代碼的質(zhì)量。 通常每個處理器都會提供一定的指令來禁止/允許中斷，因此用戶的C編譯器必須要有一定的機(jī)制來直接從C中執(zhí)行這些操作。有些編譯器能夠允許用戶在C源代碼中插入?yún)R編語言聲明。這樣就使得插入處理器指令來允許和禁止中斷變得很容易了。其它一些編譯器實(shí)際上包括了語言擴(kuò)展功能，可以直接從C中允許和禁止中斷。為了隱藏編譯器廠商提供的具體實(shí)現(xiàn)方法，μC/OS-Ⅱ定義了兩個宏來禁止和允許中斷：

OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()[L8.1(3)]。

{

OS_ENTER_CRITICAL();

/* ? μC/OS-II 臨界代碼段 */

OS_EXIT_CRITICAL();

}

方法1

執(zhí)行這兩個宏的第一個也是最簡單的方法是在OS_ENTER_CRITICAL()中調(diào)用處理器指令來禁止中斷，以及在OS_EXIT_CRITICAL()中調(diào)用允許中斷指令。但是，在這個過程中還存在著小小的問題。如果用戶在禁止中斷的情況下調(diào)用μC/OS-Ⅱ函數(shù)，在從μC/OS-Ⅱ返回的時候，中斷可能會變成是允許的了!如果用戶禁止中斷就表明用戶想在從μC/OS-Ⅱ函數(shù)返回的時候中斷還是禁止的。在這種情況下，光靠這種執(zhí)行方法可能是不夠的。

方法2

執(zhí)行OS_ENTER_CRITICAL()的第二個方法是先將中斷禁止?fàn)顟B(tài)保存到堆棧中，然后禁止中斷。而執(zhí)行OS_EXIT_CRITICAL()的時候只是從堆棧中恢復(fù)中斷狀態(tài)。如果用這個方法的話，不管用戶是在中斷禁止還是允許的情況下調(diào)用μC/OS-Ⅱ服務(wù)，在整個調(diào)用過程中都不會改變中斷狀態(tài)。如果用戶在中斷禁止的時候調(diào)用μC/OS-Ⅱ服務(wù)，其實(shí)用戶是在延長應(yīng)用程序的中斷響應(yīng)時間。用戶的應(yīng)用程序還可以用OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()來保護(hù)代碼的臨界段。 但是， 用戶在使用這種方法的時候還得十分小心，因?yàn)槿绻脩粼谡{(diào)用象OSTimeDly()之類的服務(wù)之前就禁止中斷，很有可能用戶的應(yīng)用程序會崩潰。發(fā)生這種情況的原因是任務(wù)被掛起直到時間期滿，而中斷是禁止的，因而用戶不可能獲得節(jié)拍中斷!很明顯，所有的PEND調(diào)用都會涉及到這個問題，用戶得十分小心。一個通用的辦法是用戶應(yīng)該在中斷允許的情況下調(diào)用μC/OS-Ⅱ的系統(tǒng)服務(wù)!

問題是：哪種方法更好一點(diǎn)?這就得看用戶想犧牲些什么。如果用戶并不關(guān)心在調(diào)用μC/OS-Ⅱ服務(wù)后用戶的應(yīng)用程序中中斷是否是允許的，那么用戶應(yīng)該選擇第一種方法執(zhí)行。

如果用戶想在調(diào)用μC/OS-Ⅱ服務(wù)過程中保持中斷禁止?fàn)顟B(tài)，那么很明顯用戶應(yīng)該選擇第二種方法。

給用戶舉個例子吧，通過執(zhí)行STI命令在Intel80186上禁止中斷，并用CLI命令來允許中斷。用戶可以用下面的方法來執(zhí)行這兩個宏：

#defineOS_ENTER_CRITICAL()asmCLI

#defineOS_EXIT_CRITICAL()asmSTI

CLI和SCI指令都會在兩個時鐘周期內(nèi)被馬上執(zhí)行(總共為四個周期)。為了保持中斷狀態(tài)，用戶需要用下面的方法來執(zhí)行宏：

#defineOS_ENTER_CRITICAL()asmPUSHF;CLI

#defineOS_EXIT_CRITICAL()asmPOPF

在這種情況下，OS_ENTER_CRITICAL()需要12個時鐘周期，而OS_EXIT_CRITICAL()需要另外的8個時鐘周期(總共有20個周期)。這樣，保持中斷禁止?fàn)顟B(tài)要比簡單的禁止/允許中斷多花16個時鐘周期的時間(至少在80186上是這樣的)。當(dāng)然，如果用戶有一個速度比較快的處理器(如IntelPentiumⅡ),那么這兩種方法的時間差別會很小。