基于μC/OS-II的CAN總線驅(qū)動(dòng)程序設(shè)計(jì)
引言
本文引用地址:http://www.ex-cimer.com/article/201609/303942.htm應(yīng)用實(shí)時(shí)多任務(wù)操作系統(tǒng)(RTOS)作為嵌入式設(shè)計(jì)的基礎(chǔ)和開發(fā)平臺(tái)將成為嵌入式應(yīng)用設(shè)計(jì)的主流。μC/OS-II是一種源碼公開、可移植性、可固化、可裁剪、占先式的實(shí)時(shí)多任務(wù)操作系統(tǒng),目前已經(jīng)得到廣泛的應(yīng)用。
在為電力系統(tǒng)接地選線裝置開發(fā)的數(shù)據(jù)采集監(jiān)測系統(tǒng)的設(shè)計(jì)中,筆者設(shè)計(jì)了集散式的數(shù)據(jù)采集結(jié)構(gòu),靈活的組態(tài)適應(yīng)了目前國內(nèi)多數(shù)中低壓輸配電網(wǎng)的數(shù)據(jù)采集需求。在此硬件平臺(tái)上,筆者將實(shí)時(shí)操作系統(tǒng) μC/OS-II移植到TMS320LF2407A型號的DSP上,實(shí)現(xiàn)了多任務(wù)的并行執(zhí)行,系統(tǒng)的可靠性和實(shí)時(shí)性得到大幅提升;設(shè)計(jì)了CAN總線驅(qū)動(dòng)程序,使得下位采集處理模塊與上位的主控制器具備了可靠快速的通信功能和協(xié)調(diào)功能。
1.集散式的數(shù)據(jù)采集系統(tǒng)設(shè)計(jì)
系統(tǒng)的整體結(jié)構(gòu)如圖1所示:
圖1集散式選線系統(tǒng)整體結(jié)構(gòu)
圖中反映出目前變電站常見的網(wǎng)絡(luò)結(jié)構(gòu)。一般的基于集中式數(shù)據(jù)采集方式在應(yīng)用上存在一定的缺點(diǎn),比如針對不同變電站實(shí)際情況配置不夠靈活等。而基于集散式的數(shù)據(jù)采集系統(tǒng)卻具有系統(tǒng)適應(yīng)能力強(qiáng),組態(tài)方便,可靠性高等優(yōu)點(diǎn)。因此,根據(jù)變電站網(wǎng)絡(luò)的這種結(jié)構(gòu),本裝置設(shè)計(jì)采用集散式數(shù)據(jù)采集的方式,即在每條支路上均掛接一個(gè)獨(dú)立的智能數(shù)據(jù)采集及處理模塊負(fù)責(zé)實(shí)時(shí)采集和數(shù)據(jù)預(yù)處理;主控制器與各智能采集處理模塊通過CAN現(xiàn)場總線進(jìn)行通訊,從而不僅實(shí)現(xiàn)主控的功能,還具備靈活的集散擴(kuò)充性能。
2.CAN總線接口的設(shè)計(jì)
在各種現(xiàn)場總線網(wǎng)絡(luò)中,最早為汽車電子設(shè)備互連而開發(fā)的CAN總線由于其簡單靈活的配置以及強(qiáng)大的實(shí)時(shí)控制和檢錯(cuò)糾錯(cuò)能力而在諸多自動(dòng)化領(lǐng)域中得到了廣泛的使用。
美國TI公司DSP產(chǎn)品線中的2000系列是專為工業(yè)控制應(yīng)用設(shè)計(jì)的數(shù)字信號處理器,具有強(qiáng)大的數(shù)字信號處理能力,還集成了豐富的外設(shè)和I/O,成為現(xiàn)代電機(jī)控制、電力系統(tǒng)自動(dòng)化等應(yīng)用中很好選擇。在這款DSP處理器上,自帶了兼容CAN2.0B標(biāo)準(zhǔn)的CAN總線控制器,因此只需外接一片CAN總線收發(fā)芯片即可使模塊具有完整的CAN總線通信能力,在此使用支持1Mbps的PCA82C250收發(fā)器芯片,接口設(shè)計(jì)見圖2。
圖2采集模塊CAN總線接口
3.μC/OS-II在2407上的移植
絕大部分μC/OS-II的源碼是用移植性很強(qiáng)的ANSIC寫的,只有和微處理器硬件相關(guān)的那部分是用匯編語言寫的。而TI公司提供的編譯器CodeComposerStudio(C2000)V2.20支持C語言和匯編語言開發(fā),筆者在此編譯器的基礎(chǔ)上完成了μC/OS-II的移植。移植工作主要集中在三個(gè)文件的修改工作:修改頭文件OS_CPU.H相關(guān)的內(nèi)容,包括:數(shù)據(jù)類型定義、堆棧增長方向、中斷相關(guān)的一些宏定義等;OS_CPU_C.C中編寫任務(wù)堆棧初始化函數(shù)及系統(tǒng)HOOK函;OS_CPU_A.ASM中編寫四個(gè)匯編語言函數(shù):OSStartHighRdy(),OSCtxSw(),OSIntCtxSw()和OsTickISR()。
具體移植過程由于不是本文重點(diǎn),恕筆者不再詳述。
4.基于緩沖隊(duì)列支持下的CAN總線驅(qū)動(dòng)程序設(shè)計(jì)
驅(qū)動(dòng)程序是連接底層的硬件和上層的API函數(shù)的紐帶,有了驅(qū)動(dòng)程序模塊,就可以把操作系統(tǒng)的API函數(shù)和底層的硬件分開來。任何一個(gè)硬件的改變、刪除或者添加,只需要隨之改變、刪除或者添加提供給操作系統(tǒng)的相應(yīng)的驅(qū)動(dòng)程序就可以了,并不會(huì)影響到API函數(shù)的功能,更不會(huì)影響到用戶的應(yīng)用程序。同時(shí),為了保證在實(shí)時(shí)多任務(wù)操作系統(tǒng)中,對硬件訪問的唯一性,系統(tǒng)的驅(qū)動(dòng)程序要受控于相應(yīng)的操作系統(tǒng)的多任務(wù)之間的同步機(jī)制。
(1)μC/OS-II的通信機(jī)制
μC/OS-II在處理任務(wù)之間的通信和同步的時(shí)候,主要通過以下幾種方式:信號量(Semaphore),郵箱(Mailbox),消息隊(duì)列 (Queue)和互斥信號量(Mutex)。具體的通過事件控制塊(ECB)來實(shí)現(xiàn)。μC/OS-II中定義的數(shù)據(jù)結(jié)構(gòu)OS_EVENT能夠維護(hù)任務(wù)間通信和同步的所有信息,該數(shù)據(jù)結(jié)構(gòu)不僅包含了事件本身的定義,如信號量的計(jì)數(shù)器、指向郵箱的指針、指向消息隊(duì)列的指針數(shù)組、互斥量中能否獲得資源的Flag 和正在使用該互斥量的任務(wù),還定義了等待該事件的所有任務(wù)列表。事件發(fā)生后,等待的優(yōu)先級最高的任務(wù)進(jìn)入就緒態(tài)。
(2)緩沖隊(duì)列的設(shè)計(jì)和通信任務(wù)的配合
在微機(jī)系統(tǒng)中,一般串行設(shè)備或者其他字符型設(shè)備都存在外設(shè)處理速度和CPU速度不匹配的問題,所以需要建立相應(yīng)的緩沖區(qū)。向CAN口發(fā)送數(shù)據(jù)時(shí),只要把數(shù)據(jù)寫到緩沖區(qū),然后由CAN控制器逐個(gè)取出往外發(fā)送。從CAN口接收數(shù)據(jù)時(shí),往往等收到若干個(gè)字節(jié)后才需要CPU進(jìn)行處理,所以這些預(yù)收的數(shù)據(jù)可以先存在緩沖區(qū)。緩沖區(qū)可以設(shè)置收到若干個(gè)字節(jié)后再中斷CPU,這樣就避免了因?yàn)镃PU的頻繁中斷而降低系統(tǒng)的實(shí)時(shí)性。
在對緩沖區(qū)讀寫的過程中,經(jīng)常會(huì)遇到想發(fā)送數(shù)據(jù)的時(shí)候,緩沖區(qū)已滿;想去讀的時(shí)候,接受緩沖卻是空的。對于用戶程序端,采用傳統(tǒng)的查詢工作方式,頻繁的讀取使得程序效率大為降低。如果引入讀、寫兩個(gè)信號量分別對緩沖區(qū)兩端的操作進(jìn)行同步,問題自然解決:用戶任務(wù)想寫但緩沖區(qū)滿時(shí),在信號量上休眠,讓CPU運(yùn)行別的任務(wù),待ISR從緩沖區(qū)讀走數(shù)據(jù)后喚醒這個(gè)休眠的任務(wù);類似的,用戶任務(wù)想讀但緩沖區(qū)空時(shí),也可以在信號量上休眠,待外部設(shè)備有數(shù)據(jù)來了再喚醒。其中,μC/OS-II的信號量提供了超時(shí)等待機(jī)制,CAN端口本身也有超時(shí)讀寫能力。
接受和發(fā)送的數(shù)據(jù)緩沖區(qū)數(shù)據(jù)結(jié)構(gòu)定義如下:
typedefstruct{
INT16UBufRxCtr;//接受緩沖中的字符的數(shù)目
OS_EVENTBufRxSem;//接受信號量
INT8UBufRxInPtr;//接收緩沖中下一個(gè)字符的寫入位置
INT8UBufRxOutPtr;//接收緩沖中下一個(gè)待讀出字符的位置
INT8UBufRx[CAN_BUF_SIZE];//接收環(huán)形緩沖區(qū)的大小
INT16UBufTxCtr;//發(fā)送緩沖中字符的數(shù)目
OS_EVENTBufTxSem;//發(fā)送信號量
INT8UBufTxInPtr;//發(fā)送緩沖中下一個(gè)字符的寫入位置
評論