基于μC/OS-II的CAN總線(xiàn)驅動(dòng)程序設計

引言

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

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

1.集散式的數據采集系統設計

系統的整體結構如圖1所示：

圖1集散式選線(xiàn)系統整體結構

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

2.CAN總線(xiàn)接口的設計

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

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

圖2采集模塊CAN總線(xiàn)接口

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

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

具體移植過(guò)程由于不是本文重點(diǎn)，恕筆者不再詳述。

4.基于緩沖隊列支持下的CAN總線(xiàn)驅動(dòng)程序設計

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

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

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

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

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

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

接受和發(fā)送的數據緩沖區數據結構定義如下：

typedefstruct{

INT16UBufRxCtr;//接受緩沖中的字符的數目

OS_EVENTBufRxSem;//接受信號量

INT8UBufRxInPtr;//接收緩沖中下一個(gè)字符的寫(xiě)入位置

INT8UBufRxOutPtr;//接收緩沖中下一個(gè)待讀出字符的位置

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

INT16UBufTxCtr;//發(fā)送緩沖中字符的數目

OS_EVENTBufTxSem;//發(fā)送信號量

INT8UBufTxInPtr;//發(fā)送緩沖中下一個(gè)字符的寫(xiě)入位置