μC/OS-Il在TMS320VC33上的可靠應(yīng)用
1 宏OS_ENTER_CRITlCAL和OS_EXIT_ CRITICAL
在μC／OS_ II中，0S_ENTER_CRITICAL和OS_ EXIT_CRITIcAL這兩個(gè)宏分別實(shí)現(xiàn)關(guān)中斷和開中斷的功能。TMS320VC33的全局中斷控制在ST寄存器的 GIE位(第13位)，GIE=1時(shí)全局允許中斷，GIE=O時(shí)全局禁止中斷。這兩個(gè)宏最簡(jiǎn)單直接的實(shí)現(xiàn)是使用與或指令修改GIE位，即“andn 2000H，st”和“0r 2000H，st”，網(wǎng) 上的移植代碼就是采用了這種方式。但這不是一個(gè)非?？煽康姆椒?，原因是TMS320VC33的流水線執(zhí)行結(jié)構(gòu)。為了提高代碼的執(zhí)行效率，TMS320VC33采取了四級(jí)流水線執(zhí)行結(jié)構(gòu)，指令的執(zhí)行分為取指令、指令解碼、讀操作數(shù)和指令執(zhí)行四個(gè)階段，每個(gè)階段都是并行執(zhí)行的。在理想情況下(即不存在流水線沖突和等待周期)，每個(gè)機(jī)器周期內(nèi)都有四條不同的指令分別位于取指、解碼、讀和執(zhí)行階段。這時(shí)每條指令都以單機(jī)器周期執(zhí)行，DSP達(dá)到其最大標(biāo)稱的指令吞吐量。當(dāng)產(chǎn)生中斷請(qǐng)求并且允許中斷時(shí)，DSP不會(huì)立即執(zhí)行中斷服務(wù)程序，而是要先禁止中斷、獲取中斷向量、保存返回地址，然后再跳轉(zhuǎn)至中斷服務(wù)程序。而以上各步都是與流水線操作同步的，在流水線結(jié)構(gòu)中，DSP對(duì)中斷響應(yīng)步驟如表1所列。
表1中，proga+l是單周期取指指令。如果prog a+l 是多周期取指指令(例如取指時(shí)含有等待狀態(tài))，中斷響應(yīng)會(huì)延遲到prog a+l執(zhí)行以后。由表1可知，DSP對(duì)中斷 的響應(yīng)是在取指邊界而不是指令的執(zhí)行邊界。假設(shè)prog a一2是關(guān)中斷指令“andn 2000H，st”，那么prog a一1、 prog a甚至prog a+l仍然是可中斷的，必須等到prog a +l執(zhí)行完畢后才能完全禁止中斷。同樣在開中斷時(shí)，緊鄰開中斷指令的后三條指令是不響應(yīng)中斷的?，F(xiàn)在考慮下面的情況：系統(tǒng)通過OS_ENTER_CRITICAL宏禁止中斷時(shí)，同時(shí)發(fā)生了中斷請(qǐng)求，并且緊鄰的三條指令是訪問全局變量的指令。此時(shí)，由于流水線結(jié)構(gòu)的執(zhí)行特點(diǎn)， DSP還是會(huì)響應(yīng)中斷，如果相應(yīng)的中斷服務(wù)程序也訪問了同樣的全局變量，這樣就可能破壞數(shù)據(jù)的一致性，造成系統(tǒng)的崩潰。為了防止這種情況，必須在改變系統(tǒng)中斷狀態(tài)時(shí)能夠消除流水線操作帶來的影響。為可靠實(shí)現(xiàn)OS_ ENTER_CRlTICAL和OS_EXIT_CRITICAL宏，在修改 ST寄存器之前加一條指令“RPTS O”。因?yàn)樵赗PTS指 令執(zhí)行過程中會(huì)自動(dòng)禁止中斷，并且停止流水線操作，只有RPTS指令的下一條指令執(zhí)行完畢后，DSP才會(huì)重新打開流水線。這樣就保證了改變DSP中斷狀態(tài)時(shí)不會(huì)響應(yīng)中斷，也不會(huì)執(zhí)行其他指令。上述宏的可靠實(shí)現(xiàn)為：
需要說明的是，利用trap指令的實(shí)現(xiàn)方式也是可靠的，但trap和rets／reti會(huì)兩次清除流水線，因而會(huì)對(duì)性能稍微有點(diǎn)影響。OS_ENTER_CRITICAL宏的另外兩種實(shí)現(xiàn)方法首先要保存DSP的中斷狀態(tài)，然后再改變中斷狀態(tài)。相應(yīng)的，OS_EXIT_CRlTICAL宏可直接從前面保存的狀態(tài)進(jìn)行恢復(fù)。由于流水線操作的影響，要正確保存ST寄存器的狀態(tài)，直接的存儲(chǔ)或壓棧指令是不行的，需要一些附加的保護(hù)性代碼，本文就不再深入討論了。
2 OSRdyGrp和OSRdyTbl
在筆者的應(yīng)用系統(tǒng)中，除了定時(shí)器1中斷外，還使用 了外部中斷2、DMA中斷和串口接收中斷，把這些中斷全 部打開后，會(huì)出現(xiàn)一個(gè)非常奇怪的現(xiàn)象。系統(tǒng)剛開始運(yùn)行 時(shí)一切正常，一段時(shí)間后，與idle task不在同一個(gè)優(yōu)先級(jí) 組的所有任務(wù)再也不執(zhí)行了。但從程序上看，這些任務(wù)應(yīng) 該處于就緒狀態(tài)，除非就緒任務(wù)的優(yōu)先級(jí)與idle task處于 同一個(gè)組，否則系統(tǒng)永遠(yuǎn)都在執(zhí)行idle task。通過檢查 OSRdyTbl發(fā)現(xiàn)，這些不被調(diào)度的任務(wù)的確處于就緒狀 態(tài)，但在OSRdyGrp中卻沒有設(shè)置相應(yīng)的標(biāo)志．如果在 OSRdyTbl表中任務(wù)是就緒的，與該任務(wù)優(yōu)先級(jí)組相對(duì)應(yīng) 的OSRdyGrp中的標(biāo)志卻是0，那么任務(wù)調(diào)度時(shí)這些就緒 的任務(wù)是不會(huì)被調(diào)度的。在μC／OS-II中，OSRdyGrp與 OSRdyTbl的值都是同時(shí)修改的，并且還采用了臨界區(qū)保 護(hù)，為什么還會(huì)出現(xiàn)OSRdyGrp與OSRdyTbl狀態(tài)不一致 的現(xiàn)象呢?通過對(duì)匯編代碼的仔細(xì)分析，發(fā)現(xiàn)問題出現(xiàn)在 函數(shù)OSTimeTick中，編譯器產(chǎn)生了高效但不可靠的代 碼。筆者使用的開發(fā)平臺(tái)是Code Composer V4.1，代碼 生成工具版本為5.11。此版本的代碼生成工具產(chǎn)生的 OSTimeTick函數(shù)的匯編代碼如下：
OSTimeTick函數(shù)的while循環(huán)結(jié)構(gòu)從第5行開始至第23行結(jié)束。修改OSRdyGrp的語句是第8行，可以看出對(duì)OSRdyGrp的修改沒有保存至相應(yīng)的內(nèi)存單元，而是保存在寄存器r0中，對(duì)OSRdyTbl的修改卻直接保存到了內(nèi)存單元(第14行)。位于循環(huán)體外的第4行語句將OSRdyGrp賦值給10，第24行將r0的內(nèi)容保存至OSRdyGrp。編譯器利用寄存器優(yōu)化了對(duì)OSRdyGrp的訪問，循環(huán)結(jié)構(gòu)中OSRdyGrp值的每次改變都保存在寄存器中，只是在循環(huán)開始和結(jié)束時(shí)訪問了兩次內(nèi)存，編譯器這樣的處理顯然是高效的．如果不優(yōu)化，語句“OSRdyGrp|=ptcb->OSTCBBitY”必須以讀-改-寫的方式實(shí)現(xiàn)，OSRdyGrp值的每次改變需要訪問兩次內(nèi)存，而一般情況下對(duì)內(nèi)存的訪問是耗時(shí)的．應(yīng)盡量避免。由上述代碼容易看出，這樣的優(yōu)化使得對(duì)OSRdyGrp的訪問位于臨界區(qū)以外，因而引入了不安全因素。因?yàn)樵跁r(shí)鐘節(jié)拍中斷服務(wù)程序OSTicklSR中允許嵌套中斷，所以第19行以后的語句是可中斷的。如果在20~23行之間發(fā)生了中斷，并且相應(yīng)的中斷服務(wù)程序改變了OSRdyGrp，那么第24行的賦值可能使OSRdyrp獲得一個(gè)錯(cuò)誤的結(jié)果，造成 OSRdy(jrp與C)SRdyrTbl的不一致。第4行的賦值語句同樣是危險(xiǎn)的，如果有中斷發(fā)生，rO中暫存的值不一定是當(dāng)前正確的OSRdyGrp。奇怪的是，無論采用何種編譯優(yōu)化選項(xiàng)，編譯器對(duì)OSRdyGrp的處理都是一樣的，即使禁止優(yōu)化也沒有用。在函數(shù)0S_TaskStat中對(duì)于OSStatRdy 的處理，無論采用何種編譯優(yōu)化選項(xiàng)都不會(huì)對(duì)OSStatRdy 進(jìn)行寄存器優(yōu)化。知道原因后，對(duì)這一問題的處理是非常簡(jiǎn)單的，只要在OSRdyGrp聲明時(shí)加上volatile修飾符(位于文件uCOS_II．H中)就可以禁止編譯器對(duì)OSRdyGrp 進(jìn)行寄存器優(yōu)化。給OSRdyGrp加上volatile修飾符后的編譯結(jié)果為：
與上面的第7、8行對(duì)比可以看出，對(duì)OSRdyGrp的每次修改都訪問了內(nèi)存單元，并且是在臨界區(qū)內(nèi)進(jìn)行的。
3 中斷處理程序
因?yàn)槿蝿?wù)的切換是以中斷方式進(jìn)行的，如果某個(gè)中斷向量的處理程序可能引起任務(wù)切換或者允許嵌套中斷，該中斷處理程序必須嚴(yán)格按照μC／OS_II要求的步驟進(jìn)行。其中涉及到全部寄存器的保存與恢復(fù)、特定的μC／OS_II 函數(shù)調(diào)用、任務(wù)切換的處理等。雖然Code Composer支持 C語言的中斷處理函數(shù)，但是C函數(shù)的中斷處理程序不能產(chǎn)生正確的堆棧結(jié)構(gòu)，所以最好不要直接用C語言處理中斷而是使用匯編語言。惟一的例外是中斷處理不涉及 μC／0S_II函數(shù)調(diào)用，并且禁止中斷嵌套，這時(shí)使用C語言會(huì)比較方便。時(shí)鐘節(jié)拍中斷服務(wù)程序OSTicklSR為中斷服務(wù)程序的編寫提供了一個(gè)很好的范例。OSTicklSR 采用匯編語言實(shí)現(xiàn)了寄存器的保存與恢復(fù)，以及μC／OS_H 函數(shù)調(diào)用，真正的中斷處理在C函數(shù)CSTimeTick中。用戶的中斷處理程序完全可以采用和OSTicklSR相同的匯編語言框架，然后用C函數(shù)完成實(shí)際的處理。需要說明的是，如果允許中斷嵌套，開中斷指令必須要放在OSin_ tEnter函數(shù)調(diào)用之后。如果在OSintEnter之前開中斷，嵌套的中斷服務(wù)程序不會(huì)知道自己是否是嵌套執(zhí)行的，因而可能會(huì)執(zhí)行任務(wù)切換。這樣外層中斷的堆棧將處于一個(gè)不確定的狀態(tài)，引起系統(tǒng)的崩潰。關(guān)于這一點(diǎn)，網(wǎng)上移植代碼的處理是不正確的。
結(jié)語
μC／0S-II是一個(gè)非常適合TMS320VC33的實(shí)時(shí)系統(tǒng)。因?yàn)棣藽／OS_II自身的內(nèi)存占用非常小，對(duì)于一般的系統(tǒng)而言，DSP的片上RAM就可以容納全部的操作系統(tǒng)和應(yīng)用程序代碼。試驗(yàn)表明，經(jīng)過正確移植后，系統(tǒng)具備非常高的可靠性。
下載文檔
