目前，μC／0S-II已經被成功移植到多種微處理器 上，其中也包括TMS320VC33。在μC／0S-II的網站上可以免費下載相關處理器的移植代碼，這些代碼可以作為 μC／OS-II應用中一個非常好的起點。筆者在應用這些 移植代碼時遇到了一些問題，因此如何使移植更加可靠、 高效，仍然是一個值得深入探討的話題。網上 TMS320VC33的移植代碼已經完成了基本的移植工作， 本文不對移植的詳細過程進行贅述，而只就移植及應用過程中的一些關鍵步驟和涉及到代碼可靠性的問題進行討論。

1 宏OS_ENTER_CRITlCAL和OS_EXIT_ CRITICAL

在μC／OS_ II中，0S_ENTER_CRITICAL和OS_ EXIT_CRITIcAL這兩個宏分別實現關中斷和開中斷的功能。TMS320VC33的全局中斷控制在ST寄存器的 GIE位（第13位），GIE=1時全局允許中斷，GIE=O時全局禁止中斷。這兩個宏最簡單直接的實現是使用與或指令修改GIE位，即“andn 2000H，st”和“0r 2000H，st”，網 上的移植代碼就是采用了這種方式。但這不是一個非常可靠的方法，原因是TMS320VC33的流水線執行結構。為了提高代碼的執行效率，TMS320VC33采取了四級流水線執行結構，指令的執行分為取指令、指令解碼、讀操作數和指令執行四個階段，每個階段都是并行執行的。在理想情況下（即不存在流水線沖突和等待周期），每個機器周期內都有四條不同的指令分別位于取指、解碼、讀和執行階段。這時每條指令都以單機器周期執行，DSP達到其最大標稱的指令吞吐量。當產生中斷請求并且允許中斷時，DSP不會立即執行中斷服務程序，而是要先禁止中斷、獲取中斷向量、保存返回地址，然后再跳轉至中斷服務程序。而以上各步都是與流水線操作同步的，在流水線結構中，DSP對中斷響應步驟如表1所列。

表1中，proga+l是單周期取指指令。如果prog a+l 是多周期取指指令（例如取指時含有等待狀態），中斷響應會延遲到prog a+l執行以后。由表1可知，DSP對中斷 的響應是在取指邊界而不是指令的執行邊界。假設prog a一2是關中斷指令“andn 2000H，st”，那么prog a一1、 prog a甚至prog a+l仍然是可中斷的，必須等到prog a +l執行完畢后才能完全禁止中斷。同樣在開中斷時，緊鄰開中斷指令的后三條指令是不響應中斷的。現在考慮下面的情況：系統通過OS_ENTER_CRITICAL宏禁止中斷時，同時發生了中斷請求，并且緊鄰的三條指令是訪問全局變量的指令。此時，由于流水線結構的執行特點， DSP還是會響應中斷，如果相應的中斷服務程序也訪問了同樣的全局變量，這樣就可能破壞數據的一致性，造成系統的崩潰。為了防止這種情況，必須在改變系統中斷狀態時能夠消除流水線操作帶來的影響。為可靠實現OS_ ENTER_CRlTICAL和OS_EXIT_CRITICAL宏，在修改 ST寄存器之前加一條指令“RPTS O”。因為在RPTS指 令執行過程中會自動禁止中斷，并且停止流水線操作，只有RPTS指令的下一條指令執行完畢后，DSP才會重新打開流水線。這樣就保證了改變DSP中斷狀態時不會響應中斷，也不會執行其他指令。上述宏的可靠實現為：

需要說明的是，利用trap指令的實現方式也是可靠的，但trap和rets／reti會兩次清除流水線，因而會對性能稍微有點影響。OS_ENTER_CRITICAL宏的另外兩種實現方法首先要保存DSP的中斷狀態，然后再改變中斷狀態。相應的，OS_EXIT_CRlTICAL宏可直接從前面保存的狀態進行恢復。由于流水線操作的影響，要正確保存ST寄存器的狀態，直接的存儲或壓棧指令是不行的，需要一些附加的保護性代碼，本文就不再深入討論了。

2 OSRdyGrp和OSRdyTbl

在筆者的應用系統中，除了定時器1中斷外，還使用 了外部中斷2、DMA中斷和串口接收中斷，把這些中斷全 部打開后，會出現一個非常奇怪的現象。系統剛開始運行 時一切正常，一段時間后，與idle task不在同一個優先級 組的所有任務再也不執行了。但從程序上看，這些任務應 該處于就緒狀態，除非就緒任務的優先級與idle task處于 同一個組，否則系統永遠都在執行idle task。通過檢查 OSRdyTbl發現，這些不被調度的任務的確處于就緒狀 態，但在OSRdyGrp中卻沒有設置相應的標志．如果在 OSRdyTbl表中任務是就緒的，與該任務優先級組相對應 的OSRdyGrp中的標志卻是0，那么任務調度時這些就緒 的任務是不會被調度的。在μC／OS-II中，OSRdyGrp與 OSRdyTbl的值都是同時修改的，并且還采用了臨界區保 護，為什么還會出現OSRdyGrp與OSRdyTbl狀態不一致 的現象呢？通過對匯編代碼的仔細分析，發現問題出現在 函數OSTimeTick中，編譯器產生了高效但不可靠的代 碼。筆者使用的開發平臺是Code Composer V4.1，代碼 生成工具版本為5.11。此版本的代碼生成工具產生的 OSTimeTick函數的匯編代碼如下：

OSTimeTick函數的while循環結構從第5行開始至第23行結束。修改OSRdyGrp的語句是第8行，可以看出對OSRdyGrp的修改沒有保存至相應的內存單元，而是保存在寄存器r0中，對OSRdyTbl的修改卻直接保存到了內存單元（第14行）。位于循環體外的第4行語句將OSRdyGrp賦值給10，第24行將r0的內容保存至OSRdyGrp。編譯器利用寄存器優化了對OSRdyGrp的訪問，循環結構中OSRdyGrp值的每次改變都保存在寄存器中，只是在循環開始和結束時訪問了兩次內存，編譯器這樣的處理顯然是高效的．如果不優化，語句“OSRdyGrp|=ptcb-》OSTCBBitY”必須以讀-改-寫的方式實現，OSRdyGrp值的每次改變需要訪問兩次內存，而一般情況下對內存的訪問是耗時的．應盡量避免。由上述代碼容易看出，這樣的優化使得對OSRdyGrp的訪問位于臨界區以外，因而引入了不安全因素。因為在時鐘節拍中斷服務程序OSTicklSR中允許嵌套中斷，所以第19行以后的語句是可中斷的。如果在20“23行之間發生了中斷，并且相應的中斷服務程序改變了OSRdyGrp，那么第24行的賦值可能使OSRdyrp獲得一個錯誤的結果，造成 OSRdy（jrp與C）SRdyrTbl的不一致。第4行的賦值語句同樣是危險的，如果有中斷發生，rO中暫存的值不一定是當前正確的OSRdyGrp。奇怪的是，無論采用何種編譯優化選項，編譯器對OSRdyGrp的處理都是一樣的，即使禁止優化也沒有用。在函數0S_TaskStat中對于OSStatRdy 的處理，無論采用何種編譯優化選項都不會對OSStatRdy 進行寄存器優化。知道原因后，對這一問題的處理是非常簡單的，只要在OSRdyGrp聲明時加上volatile修飾符（位于文件uCOS_II．H中）就可以禁止編譯器對OSRdyGrp 進行寄存器優化。給OSRdyGrp加上volatile修飾符后的編譯結果為：

與上面的第7、8行對比可以看出，對OSRdyGrp的每次修改都訪問了內存單元，并且是在臨界區內進行的。

3 中斷處理程序

因為任務的切換是以中斷方式進行的，如果某個中斷向量的處理程序可能引起任務切換或者允許嵌套中斷，該中斷處理程序必須嚴格按照μC／OS_II要求的步驟進行。其中涉及到全部寄存器的保存與恢復、特定的μC／OS_II 函數調用、任務切換的處理等。雖然Code Composer支持 C語言的中斷處理函數，但是C函數的中斷處理程序不能產生正確的堆棧結構，所以最好不要直接用C語言處理中斷而是使用匯編語言。惟一的例外是中斷處理不涉及 μC／0S_II函數調用，并且禁止中斷嵌套，這時使用C語言會比較方便。時鐘節拍中斷服務程序OSTicklSR為中斷服務程序的編寫提供了一個很好的范例。OSTicklSR 采用匯編語言實現了寄存器的保存與恢復，以及μC／OS_H 函數調用，真正的中斷處理在C函數CSTimeTick中。用戶的中斷處理程序完全可以采用和OSTicklSR相同的匯編語言框架，然后用C函數完成實際的處理。需要說明的是，如果允許中斷嵌套，開中斷指令必須要放在OSin_ tEnter函數調用之后。如果在OSintEnter之前開中斷，嵌套的中斷服務程序不會知道自己是否是嵌套執行的，因而可能會執行任務切換。這樣外層中斷的堆棧將處于一個不確定的狀態，引起系統的崩潰。關于這一點，網上移植代碼的處理是不正確的。

結語

μC／0S-II是一個非常適合TMS320VC33的實時系統。因為μC／OS_II自身的內存占用非常小，對于一般的系統而言，DSP的片上RAM就可以容納全部的操作系統和應用程序代碼。試驗表明，經過正確移植后，系統具備非常高的可靠性。

責任編輯：gt