CAN Driver Design Based on μC/OSII※
Cheng Jin，Shi Guoliang
(College of Electronic and Information,Soochow University,Suzhou 215006,China)
Abstract： Realtime performance is an important measuring standard for the performance of CAN field bus system. A CAN driver design is proposed to improve the realtime performance of CAN bus system at the application level by using μC/OSII and ICAN protocol. The design process of CAN driver is introduced by a layered approach.
Key words: CAN bus; μC/OSII; realtime performance; driver
引言
CAN總線是德國Bosch公司于1983年針對汽車應用而開發(fā)的，一種能有效支持分布式控制和實時控制的串行通信網(wǎng)絡，屬于現(xiàn)場總線的范疇。其通信距離與波特率有關，最大通信距離可達10 km，最大通信波特率可達1 Mbps。CAN總線仲裁采用11位（CAN2.0A協(xié)議）和29位（CAN2.0B協(xié)議）標志，以及非破壞性仲裁總線結構機制，可以確定數(shù)據(jù)塊的優(yōu)先級，保證在網(wǎng)絡節(jié)點沖突時最高優(yōu)先級節(jié)點不需要沖突等待。CAN總線上的任何節(jié)點均可在任意時刻，主動向網(wǎng)絡上其他節(jié)點發(fā)送信息而不分主次，從而實現(xiàn)各節(jié)點之間的自由通信。目前，CAN總線協(xié)議已被國際標準化組織認證，技術比較成熟，已廣泛應用于汽車、工業(yè)、高速網(wǎng)絡和低價位多路連線等領域中。
μC/OSII是Jean J.Labrosse開發(fā)的一種小型嵌入式操作系統(tǒng)。它實質上是基于優(yōu)先級的可剝奪型內(nèi)核，系統(tǒng)中的所有任務都有一個唯一的優(yōu)先級別，適合應用于實時性要求較強的場合。本文采用μC/OSII來設計CAN的驅動程序，以滿足系統(tǒng)的實時要求。
1 CAN節(jié)點的硬件設計
圖1 CAN節(jié)點基本結構
CAN節(jié)點是分布在CAN網(wǎng)絡中進行相互通信的基本單元，主要由主控制器、CAN控制器和CAN收發(fā)器組成。本設計中，節(jié)點的基本結構如圖1所示。在CAN網(wǎng)絡中，ECU(Electronic Control Unit)是指一個具有完整功能的CAN節(jié)點。
采用NXP公司的LPC2368作為CAN節(jié)點的主控制器。LPC2368是一款基于ARM7TDMIS內(nèi)核的RISC處理器，包含2個兼容CAN2.0B規(guī)范的CAN控制器。每個CAN控制器擁有雙重接收緩沖器和三態(tài)發(fā)送緩沖器，具有快速的硬件實現(xiàn)的搜索算法，可以支持大量的CAN標識符。
LPC2368是一款3.3 V器件，雖然其對應的CAN收發(fā)器接口引腳能夠承受5 V電壓，但為了讓CAN節(jié)點能夠更穩(wěn)定地運行，這里采用TI公司的3.3 V CAN收發(fā)器SN65HVD230D與之配合使用。憑借高輸入阻抗特性，SN65HVD230D可以在一條總線上支持多達120個CAN節(jié)點，并且能夠和5 V的CAN收發(fā)器良好地兼容。本文重點介紹CAN驅動程序的設計方法。
2 CAN驅動程序設計總體思想
圖2 驅動程序分層結構
為了使軟件可移植性強、易于維護，采用分層的方法編寫CAN驅動程序。驅動程序分層結構如圖2所示。圖中，雙向箭頭表示實時操作系統(tǒng)μC/OSII與CAN驅動程序之間的數(shù)據(jù)交換，單向箭頭表示上層軟件對下層軟件的調用。
3 CAN設備控制層和CAN接口控制層
CAN設備控制層的主要任務是：初始化主控制器與CAN控制器之間的連接配置，復位CAN控制器，建立主控制器和CAN控制器之間的通信函數(shù)。由于LPC2368內(nèi)部集成了CAN控制器，CPU可以通過內(nèi)部APB總線接口對CAN控制器的所有寄存器進行訪問，所以不再需要編寫設備控制驅動層程序，已經(jīng)完全由硬件實現(xiàn)了。
CAN接口控制層主要任務是：實現(xiàn)CAN控制器的各種功能，如設置控制模式、發(fā)送數(shù)據(jù)、釋放接收緩沖區(qū)、配置驗收濾波器等。這些操作都是通過讀寫CAN控制器的內(nèi)部相關寄存器來實現(xiàn)的。
CAN控制器初始化程序（在應用層中實現(xiàn)，內(nèi)部調用的函數(shù)也都是在該層中編寫的）如下：
voidCAN20B_Init() {
#ifCAN1_EN > 0
while((CAN1MOD & CAN_MOD_RM)!=1)
CAN1_MOD_RM ();//進入復位模式
CAN1_BTR ();//配置總線定時寄存器
ID_RAM ();//配置驗收濾波器
while((CAN2MOD & CAN_MOD_NM)!=1)
CAN1_MOD_NM_SET();//進入正常模式
CAN1_INT_EN ();//中斷使能寄存器設置
#endif
}
為了使程序更加簡潔、可讀性更強，可以通過宏定義的形式進行編寫。例如：
#define CAN_MOD_RM () CAN1MOD |= 1
CAN1MOD是CAN控制器的模式寄存器，最低位置1可使CAN控制器進入復位模式。這種模式下，可以對控制器的所有寄存器進行寫操作。其他對CAN控制器內(nèi)部寄存器的操作可以參照LPC2368的技術手冊。
4 CAN協(xié)議層
從OSI網(wǎng)絡模型的角度來看，現(xiàn)場總線網(wǎng)絡一般實現(xiàn)了第1層（物理層）、第2層（數(shù)據(jù)鏈路層）、第7層（應用層）；而CAN現(xiàn)場總線僅僅定義了第1層、第2層，這兩層分別由CAN收發(fā)器和CAN控制器實現(xiàn)。CAN總線沒有規(guī)定應用層，本身并不完整，因此需要一個高層協(xié)議來定義CAN報文中11/29位標識符、8字節(jié)的使用。目前，已經(jīng)有一些國際上標準的CAN總線高層協(xié)議，例如DeviceNet協(xié)議和CANopen協(xié)議；但是這個協(xié)議規(guī)范比較復雜，理解和開發(fā)難度都比較大，對于一些并不復雜的基于CAN總線的控制網(wǎng)絡不太適合。本設計采用國內(nèi)周立功CAN開發(fā)組織根據(jù)實際應用制定的簡單的CAN應用層協(xié)議ICAN協(xié)議，作為軟件設計的CAN協(xié)議層。ICAN協(xié)議中的29位幀標識符定義如表1所列。
表1 ICAN協(xié)議中29位幀標識符定義
CAN總線仲裁是從標識符的最高位（28位）開始逐位進行的。每一個發(fā)送器都對發(fā)送位的電平與被監(jiān)控的總線電平進行比較：如果相同，則這個單元可以繼續(xù)發(fā)送；如果發(fā)送的是“隱性”（邏輯1）電平，而監(jiān)控到的卻為“顯性”（邏輯0）電平，那么該單元就失去了仲裁，必須退出發(fā)送狀態(tài)。根據(jù)ICAN源節(jié)點編號部分可以看出，節(jié)點的地址編號越小，優(yōu)先級也就越高，在仲裁時能夠優(yōu)先獲得總線使用權。在CAN網(wǎng)絡系統(tǒng)中，節(jié)點越重要，分配的地址編號的優(yōu)先級相應地也越高。譬如，車載網(wǎng)絡中的發(fā)動機電控單元就應該比定向大燈電控單元的優(yōu)先級高，這樣才能保證重要的報文及時傳送出去。在節(jié)點接收到報文之后，應用程序依據(jù)ICAN協(xié)議解析報文標識符，并實現(xiàn)其指定的功能。
5 CAN應用層
CAN應用層實現(xiàn)CAN控制器的所有功能。CAN設備控制驅動層、CAN接口驅動層和CAN協(xié)議層都在應用層的控制之中。應用層主要實現(xiàn)的任務包括：
① 初始化CAN控制器，以及與應用層相關的全局變量。
② 編寫CAN控制器的中斷服務程序。
③ 報文處理任務。該任務基于ICAN協(xié)議來解析報文，并實現(xiàn)報文指示的功能。
④ 報文發(fā)送任務。該任務存儲未能發(fā)送的報文，并在發(fā)送緩沖區(qū)可用的情況下自動發(fā)送報文。
初始化CAN控制器的程序詳見第3節(jié)。由于初始化CAN控制器直接和CAN物理層及鏈路層的性能掛鉤，因此只有依據(jù)具體應用環(huán)境正確地配置CAN控制器，才能使系統(tǒng)穩(wěn)定地運行。
5.1 中斷服務程序
中斷服務程序用來判斷CAN控制器的中斷類型，并作出相應的響應。具體程序如下：
voidCAN1_ISR() {
INT32u can1_i_st;
VICVectAddr =0x0; //更新VIC優(yōu)先級硬件
OSIntEnter();
can1_i_st = CAN1ICR;//讀中斷和捕獲寄存器
if (can1_i_st!=0) {
if(can1_i_st&CAN_RI)//接收中斷
CAN1_RI_HANDLE();
if(can1_i_st&CAN_TI1){//發(fā)送中斷1
if(TX_CNT>0)
OSSemPost(CAN_TX_OVER);
}
if(can1_i_st&CAN_TI2) {//發(fā)送中斷2
if(TX_CNT>0)
OSSemPost(CAN_TX_OVER;
}
if(can1_i_st&CAN_TI3) {//發(fā)送中斷3
if(TX_CNT>0)
OSSemPost(CAN_TX_OVER);
}
if(can1_i_st&CAN_BEI)//總線錯誤中斷
CAN1_BEI_HANDLE();
}
OSIntExit();//中斷級任務切換
}
這里只對接收中斷、發(fā)送中斷以及總線錯誤中斷進行闡述，其他類型的CAN中斷處理應根據(jù)具體系統(tǒng)進行具體設計。
5.1.1 接收中斷
接收中斷處理函數(shù)CAN1_RI_HANDLE()負責接收報文，并將報文發(fā)送到任務的消息隊列中。其代碼如下：
void CAN1_RI_HANDLE() {
RI_DATA.FRAME = CAN1RFS;
RI_DATA.ID = CAN1RID;
RI_DATA.DataA = CAN1RDA;
RI_DATA.DataB =CAN1RDB;
OSQPost(CAN1_Q_RX,&RI_DATA);//向消息隊列發(fā)送消息
CAN1_COMMAND_RRB();//釋放接收緩沖區(qū)
}
其中，RI_DATA為定義的結構體CAN_MSG變量；CAN1RFS、CAN1RID、CAN1RDA和CAN1RDB分別為CAN控制器存儲接收報文幀信息、標識符、數(shù)據(jù)字節(jié)的寄存器。CAN_MSG結構體如下所示：
structCAN_MSG{
INT32uFRAME;//存放報文幀信息
INT32uID;//存放報文標識符
INT32uDataA;//存放報文前4個字節(jié)數(shù)據(jù)
INT32uDataB;//存放報文后4個字節(jié)數(shù)據(jù)
};
5.1.2 發(fā)送中斷
當發(fā)送中斷處理函數(shù)通過TX_CNT判斷出報文發(fā)送函數(shù)的消息隊列中有待發(fā)送報文時，通過函數(shù)OSSemPost(CAN_TX_OVER)向其發(fā)送信號量，通知其可以發(fā)送報文了。若TX_CNT為0，說明消息隊列中沒有待發(fā)送的報文，則不發(fā)送信號量。
5.1.3 總線錯誤中斷
CAN1_BEI_HANDLE()通過查詢中斷和捕獲寄存器來判斷是何種錯誤類型，并將它記錄下來以便于系統(tǒng)診斷。
由于CAN1_RI_HANDLE()和OSSemPost()都可能就緒等待中的任務，所以為了保證系統(tǒng)能夠嚴格按照優(yōu)先級來執(zhí)行任務。程序采用OSIntExit()函數(shù)進行中斷級任務切換，在執(zhí)行完中斷服務程序后運行一個具有最高級別的任務，而不是返回被中斷的任務。
5.2 應用層面臨的問題及解決方法
下面將結合應用層面臨的實際問題，對報文處理和報文發(fā)送函數(shù)進行詳細闡述。
?、?CAN節(jié)點將CAN中斷設為FIQ中斷，而其他中斷設為不同優(yōu)先級的IRQ中斷。由于FIQ中斷能夠打斷IRQ中斷，所以節(jié)點在任何情況下都能盡快地響應CAN中斷，提高了系統(tǒng)的實時性。
編寫的CAN中斷服務程序應該越短越好，在不影響系統(tǒng)性能的情況下盡量將中斷服務任務放到中斷服務程序外執(zhí)行，以便盡早退出FIQ中斷模式，從而使節(jié)點能夠響應新的中斷，減少系統(tǒng)中的中斷延時。其中，接收中斷處理是最占用節(jié)點資源的，它不僅需要根據(jù)ICAN協(xié)議對報文進行解析，還需要執(zhí)行報文指定的功能，所以必須放到中斷服務程序外執(zhí)行。解決的辦法是，通過μC/OSII中的OSTaskCreate（）函數(shù)建立一個報文處理任務，這個任務由一個請求消息隊列函數(shù)OSQPend()和一個報文解析處理函數(shù)組成。報文處理函數(shù)如下：
voidCAN_RMSG_HANDLE(void* ptmr) {
ptmr = ptmr;
for( ; ; ) {
OSQPend(CAN1_Q_RX,0,&CAN_Q_ERROR);//根據(jù)ICAN協(xié)議解析報文實現(xiàn)報文指定功能
}
}
如果需要發(fā)送CAN報文，首先要查詢是否有可用的發(fā)送緩沖區(qū)：若有則可用就直接發(fā)送，無須通過消息隊列作為中介，從而提高程序運行效率；若都被鎖定，則調用OSQPost（）將報文發(fā)送到報文發(fā)送函數(shù)的消息隊列MESSAGE_TX中，并執(zhí)行TX_CNT++操作。
?、?在繁忙的CAN網(wǎng)絡中，節(jié)點可能會由于仲裁丟失而無法及時將數(shù)據(jù)傳輸，因此必須要對待發(fā)送的數(shù)據(jù)進行存儲，等待節(jié)點獲得總線使用權時再發(fā)送出去。LPC2368的CAN控制器有一個三態(tài)發(fā)送緩沖區(qū)，最多能夠存儲3個報文。若3個緩沖區(qū)都處于鎖定狀態(tài)（報文正在等待發(fā)送或正處于發(fā)送過程），而又有一個報文需要發(fā)送，則需要額外的緩沖區(qū)先將它存儲起來，以待節(jié)點獲得總線使用權時再發(fā)送。
定義一個指針數(shù)組，把建立的消息數(shù)據(jù)緩沖區(qū)的首地址存入這個數(shù)組中，然后再調用OSQCreate（）函數(shù)來創(chuàng)建一個用于存儲發(fā)送報文的消息隊列MESSAGE_TX，最后通過OSTaskCreate（）函數(shù)建立一個負責發(fā)送報文的任務。該任務由一個請求消息隊列函數(shù)OSQPend()和一個請求信號量函數(shù)OSSemPend（）組成。報文發(fā)送函數(shù)如下：
void CAN_MESSAGE_SEND(void*ptmr ) {
ptmr = ptmr;
for( ; ; ) {
S = OSQPend(MESSAGE_TX , 0 , & Q_ERROR);
OSSemPend(CAN_TX_OVER , 0, &SEM_ERROR);
OS_ENTER_CRITICAL( );//進入臨界代碼區(qū)
SEND_TX_BUFFER( S );
TX_CNT--;
OS_EXIT_CRITICAL( );
}
}
其中，變量TX_CNT記錄MESSAGE_TX中的報文數(shù)目。任務向MESSAGE_TX發(fā)送一個報文，TX_CNT就加1；報文發(fā)送函數(shù)成功發(fā)送一個報文，TX_CNT就減1。這樣，中斷服務程序就可以根據(jù)TX_CNT來判斷是否有向CAN_TX_OVER發(fā)送信號量的必要，減少了不必要的冗余操作。
除非在CAN節(jié)點任務中有比將處理好的CAN報文發(fā)送出去更重要的任務要做，一般來講，報文發(fā)送任務在節(jié)點任務中應該具有最高的優(yōu)先級，以保證CAN系統(tǒng)的實時性。
③ LPC2368的最高運行速率可達72 MHz，而CAN最高傳輸速率為1 Mb/s。一般情況下，即使連續(xù)接收到2個報文，CPU也完全有能力在接收完第、2個報文前將第1個報文處理完畢，所以只需要建立一個報文處理任務。
還有些要完成較復雜任務的節(jié)點，譬如車載網(wǎng)絡中的中央控制部件（BSI）。在全CAN車載網(wǎng)絡中，它同時連接內(nèi)部網(wǎng)、車身網(wǎng)和舒適網(wǎng)3個網(wǎng)絡。作為汽車車載網(wǎng)絡系統(tǒng)中樞，BSI任務繁重，對CAN報文的處理經(jīng)常會被各種中斷和內(nèi)部任務打斷，所以不能保證及時處理上一次接收的CAN報文。另外，由于消息隊列是采取先進先出（FIFO）或者后進先出（LIFO）的方式來組織報文的，當消息隊列中積攢多個還沒處理的報文時，無法先取出優(yōu)先級最高的報文進行處理。為了能夠優(yōu)先處理重要設備發(fā)送過來的報文，必須針對系統(tǒng)中每個與本節(jié)點有進行CAN通信關系的節(jié)點建立一個獨立的報文處理任務。這個任務包含一個獨立的消息隊列，并且發(fā)送報文的節(jié)點優(yōu)先級越高，該任務設置的優(yōu)先級也應該越高。為此CAN1_RI_HANDLE()函數(shù)也應該做出相應的修改。修改之后的程序代碼如下所示：
void CAN1_RI_HANDLE() {
RI_DATA.FRAME = CAN1RFS;
RI_DATA.ID = CAN1RID;
RI_DATA.DataA = CAN1RDA;
RI_DATA.DataB = CAN1RDB;//解析報文標識符RI_DATA.ID中的SrcMACID段，根據(jù)解析結果使用OSQPost( )將RI_DATA發(fā)送到對應節(jié)點任務的消息隊列中
CAN1_COMMAND_RRB();//釋放接收緩沖區(qū)
}
再結合CAN鏈路層的仲裁機制，就可以保證優(yōu)先級別高的節(jié)點優(yōu)先發(fā)送報文，并被接收節(jié)點優(yōu)先處理。至此，CAN驅動程序的整個脈絡已經(jīng)非常清晰，其總體流程略——編者注。
結語
本文基于μC/OSII操作系統(tǒng)、針對實時性要求較高的CAN系統(tǒng)編寫的CAN驅動程序簡潔、高效，在不同的應用環(huán)境下只需添加相應的用戶代碼，就可以組成完整的CAN驅動程序。但在提高高優(yōu)先級節(jié)點實時性的同時，在一定程度上也降低了低優(yōu)先級節(jié)點的實時性，所以在工程應用中應根據(jù)實際需要兼顧高低優(yōu)先級節(jié)點的實時性能。