μC/OS-II的CAN驅動程序設計※

成進,施國梁

(蘇州大學 電子信息學院,蘇州 215006)

成進(碩士研究生),主要研究領域為計算機通信。

引 言

CAN總線是德國Bosch公司于1983年針對汽車應用而開發的,一種能有效支持分布式控制和實時控制的串行通信網絡,屬于現場總線的范疇。其通信距離與波特率有關,最大通信距離可達10 km,最大通信波特率可達 1 Mbps。CAN總線仲裁采用11位(CAN 2.0A協議)和29位(CAN 2.0B協議)標志,以及非破壞性仲裁總線結構機制,可以確定數據塊的優先級,保證在網絡節點沖突時最高優先級節點不需要沖突等待。CAN總線上的任何節點均可在任意時刻,主動向網絡上其他節點發送信息而不分主次,從而實現各節點之間的自由通信。目前,CAN總線協議已被國際標準化組織認證,技術比較成熟,已廣泛應用于汽車、工業、高速網絡和低價位多路連線等領域中。

μC/OS-II是Jean J.Labrosse開發的一種小型嵌入式操作系統。它實質上是基于優先級的可剝奪型內核,系統中的所有任務都有一個唯一的優先級別,適合應用于實時性要求較強的場合。本文采用μC/OS-II來設計CAN的驅動程序,以滿足系統的實時要求。

1 CAN節點的硬件設計

CAN節點是分布在CAN網絡中進行相互通信的基本單元,主要由主控制器、CAN控制器和CAN收發器組成。本設計中,節點的基本結構如圖1所示。在CAN網絡中,ECU(Electronic Control Unit)是指一個具有完整功能的CAN節點。

采用NXP公司的LPC2368作為CAN節點的主控制器。LPC2368是一款基于ARM7TDMIS內核的RISC處理器,包含2個兼容CAN2.0B規范的CAN控制器。每個CAN控制器擁有雙重接收緩沖器和三態發送緩沖器,具有快速的硬件實現的搜索算法,可以支持大量的CAN標識符。

LPC2368是一款3.3 V器件,雖然其對應的CAN收發器接口引腳能夠承受5 V電壓,但為了讓CAN節點能夠更穩定地運行,這里采用TI公司的3.3 V CAN收發器SN 65HVD230D與之配合使用。憑借高輸入阻抗特性,SN 65 HVD230D可以在一條總線上支持多達120個CAN節點,并且能夠和5 V的CAN收發器良好地兼容。本文重點介紹CAN驅動程序的設計方法。

圖1 CAN節點基本結構

2 CAN驅動程序設計總體思想

為了使軟件可移植性強、易于維護,采用分層的方法編寫CAN驅動程序。驅動程序分層結構如圖2所示。圖中,雙向箭頭表示實時操作系統μC/OS-II與CAN驅動程序之間的數據交換,單向箭頭表示上層軟件對下層軟件的調用。

圖2 驅動程序分層結構

3 CAN設備控制層和CAN接口控制層

CAN設備控制層的主要任務是:初始化主控制器與CAN控制器之間的連接配置,復位CAN控制器,建立主控制器和CAN控制器之間的通信函數。由于LPC2368內部集成了CAN控制器,CPU可以通過內部APB總線接口對CAN控制器的所有寄存器進行訪問,所以不再需要編寫設備控制驅動層程序,已經完全由硬件實現了。

CAN接口控制層主要任務是:實現CAN控制器的各種功能,如設置控制模式、發送數據、釋放接收緩沖區、配置驗收濾波器等。這些操作都是通過讀寫CAN控制器的內部相關寄存器來實現的。

CAN控制器初始化程序(在應用層中實現,內部調用的函數也都是在該層中編寫的)如下:

為了使程序更加簡潔、可讀性更強,可以通過宏定義的形式進行編寫。例如:

#define CAN_MOD_RM()CAN1MOD|=1

CAN1MOD是CAN控制器的模式寄存器,最低位置1可使CAN控制器進入復位模式。這種模式下,可以對控制器的所有寄存器進行寫操作。其他對CAN控制器內部寄存器的操作可以參照LPC2368的技術手冊。

4 CAN協議層

從OSI網絡模型的角度來看,現場總線網絡一般實現了第1層(物理層)、第2層(數據鏈路層)、第7層(應用層);而CAN現場總線僅僅定義了第1層、第2層,這兩層分別由CAN收發器和CAN控制器實現。CAN總線沒有規定應用層,本身并不完整,因此需要一個高層協議來定義CAN報文中11/29位標識符、8字節的使用。目前,已經有一些國際上標準的CAN總線高層協議,例如DeviceNet協議和CANopen協議;但是這個協議規范比較復雜,理解和開發難度都比較大,對于一些并不復雜的基于CAN總線的控制網絡不太適合。本設計采用國內周立功CAN開發組織根據實際應用制定的簡單的CAN應用層協議I-CAN協議,作為軟件設計的CAN協議層。I-CAN協議中的29位幀標識符定義如表1所列。

表1 I-CAN協議中29位幀標識符定義

CAN總線仲裁是從標識符的最高位(28位)開始逐位進行的。每一個發送器都對發送位的電平與被監控的總線電平進行比較:如果相同,則這個單元可以繼續發送;如果發送的是“隱性”(邏輯1)電平,而監控到的卻為“顯性”(邏輯0)電平,那么該單元就失去了仲裁,必須退出發送狀態。根據I-CAN源節點編號部分可以看出,節點的地址編號越小,優先級也就越高,在仲裁時能夠優先獲得總線使用權。在CAN網絡系統中,節點越重要,分配的地址編號的優先級相應地也越高。譬如,車載網絡中的發動機電控單元就應該比定向大燈電控單元的優先級高,這樣才能保證重要的報文及時傳送出去。在節點接收到報文之后,應用程序依據I-CAN協議解析報文標識符,并實現其指定的功能。

5 CAN應用層

CAN應用層實現CAN控制器的所有功能。CAN設備控制驅動層、CAN接口驅動層和CAN協議層都在應用層的控制之中。應用層主要實現的任務包括:

①初始化CAN控制器,以及與應用層相關的全局變量。

②編寫CAN控制器的中斷服務程序。

③報文處理任務。該任務基于I-CAN協議來解析報文,并實現報文指示的功能。

④報文發送任務。該任務存儲未能發送的報文,并在發送緩沖區可用的情況下自動發送報文。

初始化CAN控制器的程序詳見第3節。由于初始化CAN控制器直接和CAN物理層及鏈路層的性能掛鉤,因此只有依據具體應用環境正確地配置CAN控制器,才能使系統穩定地運行。

5.1 中斷服務程序

中斷服務程序用來判斷CAN控制器的中斷類型,并作出相應的響應。具體程序如下:

這里只對接收中斷、發送中斷以及總線錯誤中斷進行闡述,其他類型的CAN中斷處理應根據具體系統進行具體設計。

5.1.1 接收中斷

接收中斷處理函數CAN1_RI_HANDLE()負責接收報文,并將報文發送到任務的消息隊列中。其代碼如下:

其中,RI_DATA為定義的結構體CAN_MSG變量;CAN 1RFS、CAN1RID、CAN1 RDA 和 CAN1RDB 分別為CAN控制器存儲接收報文幀信息、標識符、數據字節的寄存器。CAN_MSG結構體如下所示:

5.1.2 發送中斷

當發送中斷處理函數通過TX_CNT判斷出報文發送函數的消息隊列中有待發送報文時,通過函數OSSem Post(CAN_TX_OVER)向其發送信號量,通知其可以發送報文了。若TX_CNT為0,說明消息隊列中沒有待發送的報文,則不發送信號量。

5.1.3 總線錯誤中斷

CAN1_BEI_HANDLE()通過查詢中斷和捕獲寄存器來判斷是何種錯誤類型,并將它記錄下來以便于系統診斷。

由于CAN1_RI_HANDLE()和OSSem Post()都可能就緒等待中的任務,所以為了保證系統能夠嚴格按照優先級來執行任務。程序采用OSIntExit()函數進行中斷級任務切換,在執行完中斷服務程序后運行一個具有最高級別的任務,而不是返回被中斷的任務。

5.2 應用層面臨的問題及解決方法

下面將結合應用層面臨的實際問題,對報文處理和報文發送函數進行詳細闡述。

①CAN節點將CAN中斷設為FIQ中斷,而其他中斷設為不同優先級的IRQ中斷。由于FIQ中斷能夠打斷IRQ中斷,所以節點在任何情況下都能盡快地響應CAN中斷,提高了系統的實時性。

編寫的CAN中斷服務程序應該越短越好,在不影響系統性能的情況下盡量將中斷服務任務放到中斷服務程序外執行,以便盡早退出FIQ中斷模式,從而使節點能夠響應新的中斷,減少系統中的中斷延時。其中,接收中斷處理是最占用節點資源的,它不僅需要根據I-CAN協議對報文進行解析,還需要執行報文指定的功能,所以必須放到中斷服務程序外執行。解決的辦法是,通過μC/OSII中的OSTaskCreate()函數建立一個報文處理任務,這個任務由一個請求消息隊列函數OSQPend()和一個報文解析處理函數組成。報文處理函數如下:

如果需要發送CAN報文,首先要查詢是否有可用的發送緩沖區:若有則可用就直接發送,無須通過消息隊列作為中介,從而提高程序運行效率;若都被鎖定,則調用OSQPost()將報文發送到報文發送函數的消息隊列MESSAGE_TX中,并執行TX_CNT++操作。

②在繁忙的CAN網絡中,節點可能會由于仲裁丟失而無法及時將數據傳輸,因此必須要對待發送的數據進行存儲,等待節點獲得總線使用權時再發送出去。LPC2368的CAN控制器有一個三態發送緩沖區,最多能夠存儲3個報文。若3個緩沖區都處于鎖定狀態(報文正在等待發送或正處于發送過程),而又有一個報文需要發送,則需要額外的緩沖區先將它存儲起來,以待節點獲得總線使用權時再發送。

定義一個指針數組,把建立的消息數據緩沖區的首地址存入這個數組中,然后再調用OSQCreate()函數來創建一個用于存儲發送報文的消息隊列MESSAGE_TX,最后通過OSTaskCreate()函數建立一個負責發送報文的任務。該任務由一個請求消息隊列函數OSQPend()和一個請求信號量函數OSSemPend()組成。報文發送函數如下:

其中,變量TX_CNT記錄MESSAGE_TX中的報文數目。任務向MESSAGE_TX發送一個報文,TX_CNT就加1;報文發送函數成功發送一個報文,TX_CNT就減1。這樣,中斷服務程序就可以根據TX_CNT來判斷是否有向CAN_TX_OVER發送信號量的必要,減少了不必要的冗余操作。

除非在CAN節點任務中有比將處理好的CAN報文發送出去更重要的任務要做,一般來講,報文發送任務在節點任務中應該具有最高的優先級,以保證CAN系統的實時性。

③LPC2368的最高運行速率可達72 MHz,而CAN最高傳輸速率為1 Mb/s。一般情況下,即使連續接收到2個報文,CPU也完全有能力在接收完第、2個報文前將第1個報文處理完畢,所以只需要建立一個報文處理任務。

還有些要完成較復雜任務的節點,譬如車載網絡中的中央控制部件(BSI)。在全CAN車載網絡中,它同時連接內部網、車身網和舒適網3個網絡。作為汽車車載網絡系統中樞,BSI任務繁重,對CAN報文的處理經常會被各種中斷和內部任務打斷,所以不能保證及時處理上一次接收的CAN報文。另外,由于消息隊列是采取先進先出(FIFO)或者后進先出(LIFO)的方式來組織報文的,當消息隊列中積攢多個還沒處理的報文時,無法先取出優先級最高的報文進行處理。為了能夠優先處理重要設備發送過來的報文,必須針對系統中每個與本節點有進行CAN通信關系的節點建立一個獨立的報文處理任務。這個任務包含一個獨立的消息隊列,并且發送報文的節點優先級越高,該任務設置的優先級也應該越高。為此CAN1_RI_HANDLE()函數也應該做出相應的修改。修改之后的程序代碼如下所示:

再結合CAN鏈路層的仲裁機制,就可以保證優先級別高的節點優先發送報文,并被接收節點優先處理。至此,CAN驅動程序的整個脈絡已經非常清晰,其總體流程略——編者注。

結 語

本文基于μC/OS-II操作系統、針對實時性要求較高的CAN系統編寫的CAN驅動程序簡潔、高效,在不同的應用環境下只需添加相應的用戶代碼,就可以組成完整的CAN驅動程序。但在提高高優先級節點實時性的同時,在一定程度上也降低了低優先級節點的實時性,所以在工程應用中應根據實際需要兼顧高低優先級節點的實時性能。

編者注:本刊為期刊縮略版,全文見本刊網站www.mesnet.com.cn。

[1]王黎明,夏立,邵英,等.CAN現場總線系統的設計與應用[M].北京:電子工業出版社,2008.

[2]任哲,潘樹林,房紅征.嵌入式操作系統基礎 μC/OS-II和Linux[M].北京:北京航空航天大學出版社,2006.

[3]Daniel Rouche.汽車車載網絡(VAN/CAN/LIN)技術詳解[M].北京:機械工業出版社,2006.

[4]田靜,黃亞樓,王立文.CAN總線固定優先級調度算法的應用[J].計算機工程,2006(23).

[5]Guangzhou ZLG MCU Development CO.LPC23xx器件用戶手冊.Rev.01,2008.

[6]杜春雷.ARM體系結構與編程[M].北京:清華大學出版社,2003.