DSP Flash存儲器中運行μC/OS-II的研究

　　引言

　　在作為國家863計劃子項目挖掘機智能化控制系統(tǒng)的開發(fā)中，出現(xiàn)了智能化挖掘機軌跡控制系統(tǒng)不按照預先設定好的軌跡運行和嵌入式實時多任務操作系統(tǒng)μC/OS-Ⅱ調度紊亂等失控問題。該智能化系統(tǒng)中采用了μC/OS-Ⅱ，通過位移傳感器實時采集挖掘機的鏟斗、斗桿和動臂等3路角度信號，通過算法規(guī)劃路徑驅動液壓比例閥實現(xiàn)平行推進、鏟斗挖掘等典型作業(yè)。本文主要針對課題遇到的問題，重點闡述μC/OS-Ⅱ在芯片內Flash存儲器運行時關鍵問題的分析與解決辦法。

　　1μC/OS-Ⅱ在Flash存儲器中的運行

　　1.1 μC/OS-Ⅱ的特點與功能

　　μC/OS-Ⅱ是一個實時多任務的嵌入式操作系統(tǒng)，它采用可剝奪型內核。所有的任務都有優(yōu)先級，多任務之間優(yōu)先級高的可以中斷執(zhí)行中的低優(yōu)先級任務而優(yōu)先執(zhí)行。

　　它的特點主要有：公開源代碼、可移植性、可固化、可裁減、支持多任務、具有可確定性等。μC/OS-Ⅱ是基于優(yōu)先級搶占式的實時多任務操作系統(tǒng)，包含了實時內核、任務管理、時間管理、任務間通信同步(信號量、郵箱、消息隊列)和內存管理等功能。

　　1.2關鍵問題

　　在完成了智能控制軟件后，就是將之嵌入到μC/OS-Ⅱ系統(tǒng)中。遇到的主要問題是移植好的μC/OS-Ⅱ源代碼在聞亭的目標板上在線仿真時，把.out文件下載到RAM中能正常執(zhí)行，但是用CCS燒寫到Flash存儲器中就不能正常執(zhí)行，出現(xiàn)智能化挖掘機軌跡控制系統(tǒng)不按照預先設定好的軌跡運行和μC/OS-Ⅱ實時多任務調度紊亂等失控問題，尤其是在課題的后期驗收階段問題尤為棘手。

　　1.3原因分析

　　程序固化的關鍵問題是如何在程序存儲器中分配存儲空間給常量和用const關鍵字定義的靜態(tài)、全局變量。經(jīng)過仔細研究，發(fā)現(xiàn)與TI的C編譯器功能有關。CCS的編譯器按照標準C，沒有對Flash ROM中常數(shù)數(shù)據(jù)進行直接訪問的功能。所以必須讓const段的常量數(shù)據(jù)在RAM中。

　　實現(xiàn)這一條件的方法有3種：

　　a)方法1：解決μC/OS-Ⅱ在Flash中運行的方法，采用去除const關鍵字，在程序中賦初值使用，并且需要在.cmd文件中將.cinit段分配到程序區(qū)Flash存儲空間，然后在編譯器的編譯選項中選中“-C”，即ROM初始化(C編譯器默認就是這樣的)。

　　b)方法2：不對定義作修改，.const段保存在Flash存儲器中，數(shù)據(jù)不向數(shù)據(jù)存儲器移動，程序運行時直接在程序存儲空間中訪問這些量。由于c語言缺乏訪問程序區(qū)數(shù)據(jù)的有效手段，因此這些語句只能使用匯編語言編寫。由于在每一處訪問這些常量時都必須使用這些語句，因此這樣編寫程序改動量較大。

　　c)方法3：不需要修改常量定義，也不必編寫專門的程序，主要的工作是修改.cmd文件并對工程中使用的庫文件作簡單的修改，修改工作量小而且集中，極大地方便了程序的編寫。較之前兩種方法，這種方法運用起來要方便得多。

　　2關鍵問題的解決與實現(xiàn)

　　以下分別介紹方法1和方法3的具體實現(xiàn)。

　　2.1方法1

　　解決μC/OS-Ⅱ在Flash存儲器中運行的方法，即去除const關鍵字，在程序中賦初值使用，以μC/OS-Ⅱ的更改為例：

　　2.1.1問題的發(fā)現(xiàn)

　　μC/OS-Ⅱ的程序燒寫到Flash中的問題，剛開始懷疑是分配存儲器的cmd文件有問題，然后相關的又想到程序的大小問題，特別是在咨詢聞亭的技術人員告知大于1 kB的程序要分開燒后，甚至懷疑聞亭的仿真器和開發(fā)板。后來實驗使用合眾達的板子是同樣的效果，并且發(fā)現(xiàn)不帶μC/OS的大小程序都能正常執(zhí)行，基本排除了程序大小的問題以及硬件問題。后來通過對μC/OS系統(tǒng)任務調度前加LED函數(shù)，發(fā)現(xiàn)：直到多任務調度前都能正常執(zhí)行，開始多任務調度后就出了問題。到這里確定問題出在μC/OS-Ⅱ上，但是μC/OS-Ⅱ的移植是其他人員做的，其他本身沒有做過嚴格測試，也沒有燒到Flash存儲器中運行過，對整個課題產生致命的影響。最后課題組分析了程序在Flash存儲器中運行與在RAM中運行的本質區(qū)別，提出一個重要的建議：可能有系統(tǒng)需要的常量定義在擴展RAM區(qū)了，當?shù)綦姾螅琑AM區(qū)的內容沒有了，常量也就沒有了，影響了系統(tǒng)的運行。

　　通過查看工程的cmd文件和編譯輸出的map文件，發(fā)現(xiàn)確實有系統(tǒng)內核的常量放在8000h以后的擴展RAM區(qū)。見下面map文件引用：

　　然后在OS_CORE.C中找到了常量的位置，分別是掩碼表：INT8U const OSMapTbl[]和任務優(yōu)先級判定表：INT8U const OSUnMapTbl[]

　　通過實驗發(fā)現(xiàn)，燒寫程序到Flash存儲器中之后，如果不關電源，而直接拔掉USB，從Flash存儲器引導，復位后程序能正常執(zhí)行，但是關電后就不能了。經(jīng)查看，F(xiàn)lash存儲器燒寫過程是先將程序裝載到RAM，再搬移到Flash存儲器中，所以不掉電所有程序都在RAM中有保留，但是程序確能從Flash存儲器引導。這樣，就確定了確實是這些常量放在RAM中引起的。但是并不像開始想象的那樣，把常量直接定義在Flash存儲器區(qū)就能解決，但可以通過程序賦值來初始化這些常量，而不通過編譯來初始化，這是一個不一定最好但很有效的辦法。

　　2.1.2修改方法

　　按照上面的思路，對μC/OS作了如下3處修改：

　　a)OS_CORE.C文件中上面兩個數(shù)組的上面的初始化定義改為下面兩個初始化函數(shù)：