μC／OS-II的CAN驅動(dòng)程序設計

5．1．2 發(fā)送中斷
當發(fā)送中斷處理函數通過(guò)TX_CNT判斷出報文發(fā)送函數的消息隊列中有待發(fā)送報文時(shí)，通過(guò)函數OSSemPost(CAN_TX_OVER)向其發(fā)送信號量，通知其可以發(fā)送報文了。若TX_CNT為0，說(shuō)明消息隊列中沒(méi)有待發(fā)送的報文，則不發(fā)送信號量。
5．1．3 總線(xiàn)錯誤中斷
CANl BEI HANDLE()通過(guò)查詢(xún)中斷和捕獲寄存器來(lái)判斷是何種錯誤類(lèi)型，并將它記錄下來(lái)以便于系統診斷。
由于CANl_RI_HANDLE()和OSSemPost()都可能就緒等待中的任務(wù)，所以為了保證系統能夠嚴格按照優(yōu)先級來(lái)執行任務(wù)。程序采用OSIntEx-it()函數進(jìn)行中斷級任務(wù)切換，在執行完中斷服務(wù)程序后運行一個(gè)具有最高級別的任務(wù)，而不是返回被中斷的任務(wù)。
5．2 應用層面臨的問(wèn)題及解決方法
下面將結合應用層面臨的實(shí)際問(wèn)題，對報文處理和報文發(fā)送函數進(jìn)行詳細闡述。
①CAN節點(diǎn)將CAN中斷設為FIQ中斷，而其他中斷設為不同優(yōu)先級的IRQ中斷。由于FIQ中斷能夠打斷IRQ中斷，所以節點(diǎn)在任何情況下都能盡快地響應CAN中斷，提高了系統的實(shí)時(shí)性。
編寫(xiě)的CAN中斷服務(wù)程序應該越短越好，在不影響系統性能的情況下盡量將中斷服務(wù)任務(wù)放到中斷服務(wù)程序外執行，以便盡早退出FIQ中斷模式，從而使節點(diǎn)能夠響應新的中斷，減少系統中的中斷延時(shí)。其中，接收中斷處理是最占用節點(diǎn)資源的，它不僅需要根據I-CAN協(xié)議對報文進(jìn)行解析，還需要執行報文指定的功能，所以必須放到中斷服務(wù)程序外執行。解決的辦法是，通過(guò)μC／OS-II中的OSTaskCreate()函數建立一個(gè)報文處理任務(wù)，這個(gè)任務(wù)由一個(gè)請求消息隊列函數OSQPend()和一個(gè)報文解析處理函數組成。報文處理函數如下：

如果需要發(fā)送CAN報文，首先要查詢(xún)是否有可用的發(fā)送緩沖區：若有則可用就直接發(fā)送，無(wú)須通過(guò)消息隊列作為中介，從而提高程序運行效率；若都被鎖定，則調用OSQPost()將報文發(fā)送到報文發(fā)送函數的消息隊列MESSAGE_TX中，并執行TX_CNT++操作。
②在繁忙的CAN網(wǎng)絡(luò )中，節點(diǎn)可能會(huì )由于仲裁丟失而無(wú)法及時(shí)將數據傳輸，因此必須要對待發(fā)送的數據進(jìn)行存儲，等待節點(diǎn)獲得總線(xiàn)使用權時(shí)再發(fā)送出去。LPC2368的CAN控制器有一個(gè)三態(tài)發(fā)送緩沖區，最多能夠存儲3個(gè)報文。若3個(gè)緩沖區都處于鎖定狀態(tài)(報文正在等待發(fā)送或正
處于發(fā)送過(guò)程)，而又有一個(gè)報文需要發(fā)送，則需要額外的緩沖區先將它存儲起來(lái)，以待節點(diǎn)獲得總線(xiàn)使用權時(shí)再發(fā)送。
定義一個(gè)指針數組，把建立的消息數據緩沖區的首地址存入這個(gè)數組中，然后再調用OSQCreate()函數來(lái)創(chuàng )建一個(gè)用于存儲發(fā)送報文的消息隊列MESSAGE TX，最后通過(guò)OSTaskCreate()函數建立一個(gè)負責發(fā)送報文的任務(wù)。該任務(wù)由一個(gè)請求消息隊列函數OSQPend()和一個(gè)請求信號量函數OSSemPend()組成。報文發(fā)送函數如下：

其中，變量TX_CNT記錄MESSAGE_TX中的報文數目。任務(wù)向MESSAGE_TX發(fā)送一個(gè)報文，TX_CNT就加1；報文發(fā)送函數成功發(fā)送一個(gè)報文，TX _CNT就減1。這樣，中斷服務(wù)程序就可以根據TX_CNT來(lái)判斷是否有向CAN_TX_OVER發(fā)送信號量的必要，減少了不必要的冗余操作。
除非在CAN節點(diǎn)任務(wù)中有比將處理好的CAN報文發(fā)送出去更重要的任務(wù)要做，一般來(lái)講，報文發(fā)送任務(wù)在節點(diǎn)任務(wù)中應該具有最高的優(yōu)先級，以保證CAN系統的實(shí)時(shí)性。
③LPC2368的最高運行速率可達72 MHz，而CAN最高傳輸速率為1 Mb／s。一般情況下，即使連續接收到2個(gè)報文，CPU也完全有能力在接收完第、2個(gè)報文前將第1個(gè)報文處理完畢，所以只需要建立一個(gè)報文處理任務(wù)。
還有些要完成較復雜任務(wù)的節點(diǎn)，譬如車(chē)載網(wǎng)絡(luò )中的中央控制部件(BSI)。在全CAN車(chē)載網(wǎng)絡(luò )中，它同時(shí)連接內部網(wǎng)、車(chē)身網(wǎng)和舒適網(wǎng)3個(gè)網(wǎng)絡(luò )。作為汽車(chē)車(chē)載網(wǎng)絡(luò )系統中樞，BSI任務(wù)繁重，對CAN報文的處理經(jīng)常會(huì )被各種中斷和內部任務(wù)打斷，所以不能保證及時(shí)處理上一次接收
的CAN報文。另外，由于消息隊列是采取先進(jìn)先出(FIF0)或者后進(jìn)先出(LIFO)的方式來(lái)組織報文的，當消息隊列中積攢多個(gè)還沒(méi)處理的報文時(shí)，無(wú)法先取出優(yōu)先級最高的報文進(jìn)行處理。為了能夠優(yōu)先處理重要設備發(fā)送過(guò)來(lái)的報文，必須針對系統中每個(gè)與本節點(diǎn)有進(jìn)行CAN通信關(guān)系的節點(diǎn)建立一個(gè)獨立的報文處理任務(wù)。這個(gè)任務(wù)包含一個(gè)獨立的消息隊列，并且發(fā)送報文的節點(diǎn)優(yōu)先級越高，該任務(wù)設置的優(yōu)先級也應該越高。為此CANl_R1_HANDLE()函數也應該做出相應的修改。修改之后的程序代碼如下所示：

再結合CAN鏈路層的仲裁機制，就可以保證優(yōu)先級別高的節點(diǎn)優(yōu)先發(fā)送報文，并被接收節點(diǎn)優(yōu)先處理。至此，CAN驅動(dòng)程序的整個(gè)脈絡(luò )已經(jīng)非常清晰，其總體流程略——編者注。

結語(yǔ)
本文基于μC／OS-II操作系統、針對實(shí)時(shí)性要求較高的CAN系統編寫(xiě)的CAN驅動(dòng)程序簡(jiǎn)潔、高效，在不同的應用環(huán)境下只需添加相應的用戶(hù)代碼，就可以組成完整的CAN驅動(dòng)程序。但在提高高優(yōu)先級節點(diǎn)實(shí)時(shí)性的同時(shí)，在一定程度上也降低了低優(yōu)先級節點(diǎn)的實(shí)時(shí)性，所以在工程應用中應根據實(shí)際需要兼顧高低優(yōu)先級節點(diǎn)的實(shí)時(shí)性能。