引言

　　應(yīng)用實時多任務(wù)操作系統(tǒng)(RTOS)作為嵌入式設(shè)計的基礎(chǔ)和開發(fā)平臺將成為嵌入式應(yīng)用設(shè)計的主流。μC/OS-II是一種源碼公開、可移植性、可固化、可裁剪、占先式的實時多任務(wù)操作系統(tǒng)，目前已經(jīng)得到廣泛的應(yīng)用。

　　在為電力系統(tǒng)接地選線裝置開發(fā)的數(shù)據(jù)采集監(jiān)測系統(tǒng)的設(shè)計中，筆者設(shè)計了集散式的數(shù)據(jù)采集結(jié)構(gòu)，靈活的組態(tài)適應(yīng)了目前國內(nèi)多數(shù)中低壓輸配電網(wǎng)的數(shù)據(jù)采集需求。在此硬件平臺上，筆者將實時操作系統(tǒng)μC/OS-II移植到TMS320LF2407A型號的DSP上，實現(xiàn)了多任務(wù)的并行執(zhí)行，系統(tǒng)的可靠性和實時性得到大幅提升;設(shè)計了CAN總線驅(qū)動程序，使得下位采集處理模塊與上位的主控制器具備了可靠快速的通信功能和協(xié)調(diào)功能。

　　1. 集散式的數(shù)據(jù)采集系統(tǒng)設(shè)計

　　系統(tǒng)的整體結(jié)構(gòu)如圖1所示：

圖1 集散式選線系統(tǒng)整體結(jié)構(gòu)

　　圖中反映出目前變電站常見的網(wǎng)絡(luò)結(jié)構(gòu)。一般的基于集中式數(shù)據(jù)采集方式在應(yīng)用上存在一定的缺點，比如針對不同變電站實際情況配置不夠靈活等。而基于集散式的數(shù)據(jù)采集系統(tǒng)卻具有系統(tǒng)適應(yīng)能力強，組態(tài)方便，可靠性高等優(yōu)點。因此，根據(jù)變電站網(wǎng)絡(luò)的這種結(jié)構(gòu)，本裝置設(shè)計采用集散式數(shù)據(jù)采集的方式，即在每條支路上均掛接一個獨立的智能數(shù)據(jù)采集及處理模塊負(fù)責(zé)實時采集和數(shù)據(jù)預(yù)處理;主控制器與各智能采集處理模塊通過CAN現(xiàn)場總線進行通訊，從而不僅實現(xiàn)主控的功能，還具備靈活的集散擴充性能。

　　2. CAN總線接口的設(shè)計

　　在各種現(xiàn)場總線網(wǎng)絡(luò)中，最早為汽車電子設(shè)備互連而開發(fā)的CAN總線由于其簡單靈活的配置以及強大的實時控制和檢錯糾錯能力而在諸多自動化領(lǐng)域中得到了廣泛的使用。

　　美國TI公司DSP產(chǎn)品線中的2000系列是專為工業(yè)控制應(yīng)用設(shè)計的數(shù)字信號處理器，具有強大的數(shù)字信號處理能力，還集成了豐富的外設(shè)和I/O，成為現(xiàn)代電機控制、電力系統(tǒng)自動化等應(yīng)用中很好選擇。在這款DSP處理器上，自帶了兼容CAN2.0B標(biāo)準(zhǔn)的CAN總線控制器，因此只需外接一片CAN總線收發(fā)芯片即可使模塊具有完整的CAN總線通信能力，在此使用支持1M bps的PCA82C250收發(fā)器芯片，接口設(shè)計見圖2。

圖2 采集模塊CAN總線接口[!--empirenews.page--]

　　3. μC/OS-II在2407上的移植

　　絕大部分μC/OS-II的源碼是用移植性很強的ANSI C寫的，只有和微處理器硬件相關(guān)的那部分是用匯編語言寫的。而TI公司提供的編譯器Code Composer Studio (C2000) V2.20支持C語言和匯編語言開發(fā)，筆者在此編譯器的基礎(chǔ)上完成了μC/OS-II的移植。移植工作主要集中在三個文件的修改工作：修改頭文件OS_CPU.H相關(guān)的內(nèi)容，包括：數(shù)據(jù)類型定義、堆棧增長方向、中斷相關(guān)的一些宏定義等;OS_CPU_C.C中編寫任務(wù)堆棧初始化函數(shù)及系統(tǒng)HOOK函;OS_CPU_A.ASM中編寫四個匯編語言函數(shù)：OSStartHighRdy(), OSCtxSw(), OSIntCtxSw()和OsTickISR()。

　　具體移植過程由于不是本文重點，恕筆者不再詳述。

　　4. 基于緩沖隊列支持下的CAN總線驅(qū)動程序設(shè)計

　　驅(qū)動程序是連接底層的硬件和上層的API函數(shù)的紐帶，有了驅(qū)動程序模塊，就可以把操作系統(tǒng)的API函數(shù)和底層的硬件分開來。任何一個硬件的改變、刪除或者添加，只需要隨之改變、刪除或者添加提供給操作系統(tǒng)的相應(yīng)的驅(qū)動程序就可以了，并不會影響到API函數(shù)的功能，更不會影響到用戶的應(yīng)用程序。同時，為了保證在實時多任務(wù)操作系統(tǒng)中，對硬件訪問的唯一性，系統(tǒng)的驅(qū)動程序要受控于相應(yīng)的操作系統(tǒng)的多任務(wù)之間的同步機制。

　　(1) μC/OS-II的通信機制

　　μC/OS-II在處理任務(wù)之間的通信和同步的時候，主要通過以下幾種方式：信號量(Semaphore)，郵箱(Mailbox)，消息隊列(Queue)和互斥信號量(Mutex)。具體的通過事件控制塊(ECB)來實現(xiàn)。μC/OS-II中定義的數(shù)據(jù)結(jié)構(gòu)OS_EVENT能夠維護任務(wù)間通信和同步的所有信息，該數(shù)據(jù)結(jié)構(gòu)不僅包含了事件本身的定義，如信號量的計數(shù)器、指向郵箱的指針、指向消息隊列的指針數(shù)組、互斥量中能否獲得資源的Flag和正在使用該互斥量的任務(wù)，還定義了等待該事件的所有任務(wù)列表。事件發(fā)生后，等待的優(yōu)先級最高的任務(wù)進入就緒態(tài)。

　　(2) 緩沖隊列的設(shè)計和通信任務(wù)的配合

　　在微機系統(tǒng)中,一般串行設(shè)備或者其他字符型設(shè)備都存在外設(shè)處理速度和CPU速度不匹配的問題，所以需要建立相應(yīng)的緩沖區(qū)。向CAN口發(fā)送數(shù)據(jù)時，只要把數(shù)據(jù)寫到緩沖區(qū)，然后由CAN控制器逐個取出往外發(fā)送。從CAN口接收數(shù)據(jù)時，往往等收到若干個字節(jié)后才需要CPU進行處理，所以這些預(yù)收的數(shù)據(jù)可以先存在緩沖區(qū)。緩沖區(qū)可以設(shè)置收到若干個字節(jié)后再中斷CPU，這樣就避免了因為CPU的頻繁中斷而降低系統(tǒng)的實時性。

　　在對緩沖區(qū)讀寫的過程中，經(jīng)常會遇到想發(fā)送數(shù)據(jù)的時候，緩沖區(qū)已滿;想去讀的時候，接受緩沖卻是空的。對于用戶程序端，采用傳統(tǒng)的查詢工作方式，頻繁的讀取使得程序效率大為降低。如果引入讀、寫兩個信號量分別對緩沖區(qū)兩端的操作進行同步，問題自然解決：用戶任務(wù)想寫但緩沖區(qū)滿時，在信號量上休眠，讓CPU運行別的任務(wù)，待ISR從緩沖區(qū)讀走數(shù)據(jù)后喚醒這個休眠的任務(wù);類似的，用戶任務(wù)想讀但緩沖區(qū)空時，也可以在信號量上休眠，待外部設(shè)備有數(shù)據(jù)來了再喚醒。其中，μC/OS-II的信號量提供了超時等待機制，CAN端口本身也有超時讀寫能力。

　　接受和發(fā)送的數(shù)據(jù)緩沖區(qū)數(shù)據(jù)結(jié)構(gòu)定義如下：

　　typedef struct {

　　INT16U BufRxCtr; //接受緩沖中的字符的數(shù)目

　　OS_EVENT BufRxSem; //接受信號量

　　INT8U BufRxInPtr; //接收緩沖中下一個字符的寫入位置

　　INT8U BufRxOutPtr; //接收緩沖中下一個待讀出字符的位置

　　INT8U BufRx[CAN_BUF_SIZE]; //接收環(huán)形緩沖區(qū)的大小

　　INT16U BufTxCtr; //發(fā)送緩沖中字符的數(shù)目

　　OS_EVENT BufTxSem; //發(fā)送信號量

　　INT8U BufTxInPtr; //發(fā)送緩沖中下一個字符的寫入位置

　　INT8U BufTxOutPtr; //發(fā)送緩沖中下一個待讀出字符的位置

　　INT8U BufTx[CAN_BUF_SIZE]; //發(fā)送環(huán)形緩沖區(qū)的大小

　　}CAN_BUF;

　　其他接口函數(shù)如下：

　　Void CanInitHW ( ); //設(shè)置CAN控制器端口中斷向量

　　Void CANSendMsg ( ); //向CAN控制器端口發(fā)送數(shù)據(jù)

　　Void CANReceiveMsg ( ); //從CAN控制器端口接受數(shù)據(jù)[!--empirenews.page--]

圖3 基于緩沖隊列的CAN通信過程

　　基于緩沖隊列支持下的CAN通信任務(wù)通信過程如圖3所示。

　　在該通信任務(wù)中，采用查詢方式發(fā)送，中斷方式接收，任何時候只要沒有關(guān)中斷，中斷任務(wù)的優(yōu)先級高于其他任何任務(wù)?？梢哉f，該任務(wù)是“基于中斷響應(yīng)”的。這樣處理的好處是能夠最大的保證了通信的實時性，同時也使得系統(tǒng)資源的利用率大大提高(相比于收發(fā)都采用查詢的方式)。任務(wù)間的通信和同步通過郵箱和信號量機制進行。

　　當(dāng)用戶應(yīng)用程序(或任務(wù))要求進行遠程CAN通信的時候，應(yīng)用程序(或任務(wù))先要獲得BufTxSem并向發(fā)送緩沖區(qū)BufTx裝入報文，寫入緩沖區(qū)結(jié)束后釋放信號量BufTxSem，通過郵箱通知CAN通信任務(wù)處理報文并完成報文的發(fā)送。

　　當(dāng)總線發(fā)來報文時，接受節(jié)點的CAN控制器會產(chǎn)生一個接收中斷，當(dāng)前運行任務(wù)被掛起，CAN通信任務(wù)被激活并搶占運行，獲取信號量BufRxSem，然后從總線上讀取報文并寫入緩沖區(qū) ，寫入結(jié)束后釋放信號量BufRxSem，并通過郵箱通知相應(yīng)的用戶應(yīng)用程序(或任務(wù));應(yīng)用程序(或任務(wù))通過獲得信號量BufRxSem從緩沖區(qū)內(nèi)讀取相應(yīng)的報文信息。

　　(3) μC/OS-II的中斷任務(wù)的處理

　　在μC/OS-II中，中斷服務(wù)程序一般用匯編語言來寫。以下是中斷服務(wù)程序的示意代碼：

　　Void UserISR( void ) {

　　保存全部CPU寄存器;

　　調(diào)用OSIntEnter或OSIntNesting直接加1;

　　執(zhí)行用戶代碼做中斷服務(wù);

　　調(diào)用OSIntExit;

　　恢復(fù)所有CPU寄存器;

　　執(zhí)行中斷返回指令;

　　}

　　μC/OS-II提供了兩個ISR與內(nèi)核的接口函數(shù)：OSIntEnter和OSIntExit。OSIntEnter通知內(nèi)核中斷服務(wù)程序開始運行了，并把一個全局變量OSIntNesting加1。此中斷嵌套計數(shù)器可以確保所有中斷處理完成后再作任務(wù)調(diào)度。另一個接口函數(shù)OSIntExit則通知內(nèi)核，中斷服務(wù)已結(jié)束。根據(jù)相應(yīng)情況，返回被中斷點(可能是一個任務(wù)或者被嵌套的中斷服務(wù)程序)或由內(nèi)核作任務(wù)調(diào)度。

　　用戶編寫的ISR必須被安裝到某一位置，以便中斷發(fā)生后，CPU根據(jù)相應(yīng)的中斷向量運行準(zhǔn)確的服務(wù)程序。許多實時操作系統(tǒng)都提供了安裝、卸載中斷服務(wù)程序的API接口函數(shù)，有些成熟的RTOS甚至對中斷控制器的管理都有相應(yīng)的API函數(shù)。但 μC/OS-II內(nèi)核沒有提供類似的接口函數(shù)，需要用戶在對應(yīng)的CPU移植中自己實現(xiàn)。在DSP2407中，我們可以在設(shè)計中斷向量表的時候把用戶的中斷入口寫好，這樣一旦CAN通信接受中斷發(fā)生時，DSP2407就能自動從中斷向量表里讀取相應(yīng)的程序入口，進而跳轉(zhuǎn)執(zhí)行用戶的ISR程序。

　　結(jié)束語

　　基于RTOS平臺上開發(fā)用戶的應(yīng)用程序，便于在實時操作系統(tǒng)內(nèi)核下實現(xiàn)多任務(wù)處理，可以大大縮短產(chǎn)品開發(fā)周期，進一步提高應(yīng)用程序的可移植性和可維護性?；诒疚脑黹_發(fā)的應(yīng)用于集散式數(shù)據(jù)采集系統(tǒng)的CAN總線遠程通信構(gòu)件具有良好的可擴充性和移植性，對各種實際現(xiàn)場情況能夠進行靈活的配置和設(shè)定，真正實現(xiàn)了通信模塊驅(qū)動程序的封裝。