1 前言
控制器局域網（CAN－Controller Area Network）屬于現(xiàn)場總線（Fieldbus）的范疇，是眾多的屬于現(xiàn)場總線標準之一，它適用于工業(yè)控制系統(tǒng)，具有通信速率高、可靠性強、連接方便、性能價格比高等諸多特點。它是一種有效支持分布式控制或實時控制的串行通信網絡，以其短報文幀及CSMA/CD-AMP（帶有信息優(yōu)先權及沖突檢測的載波監(jiān)聽多路訪問）的MAC（媒介訪問控制）方式而倍受工業(yè)自動化領域中設備互連的厚愛。CAN的應用范圍遍及從高速網絡到低成本的多線路網絡，它可以應用于汽車系統(tǒng)、機械、技術設備和工業(yè)自動化里幾乎任何類型的數(shù)據(jù)通信。CAN具有如一下優(yōu)點：
1）使用簡單方便。許多CAN控制器實現(xiàn)了CAN物理層及數(shù)據(jù)鏈路層的大部分功能，用戶只須對CAN控制器進行初始化和對CAN總線上的數(shù)據(jù)進行收發(fā)操作即可實現(xiàn)通信；
2）高可靠性。CAN上的最大通信速率可達1Mbps，CAN總線是多主節(jié)點，各節(jié)點通過總線仲裁獲得總線控制權。完善的錯誤處理機制保證了高噪聲干擾環(huán)境下數(shù)據(jù)傳送的安全可靠；
3）系統(tǒng)可擴展性能好。CAN總線是基于發(fā)送報文的編碼，而不是對CAN控制節(jié)點進行編碼，故增添或刪除CAN節(jié)點不會對系統(tǒng)造成太大的影響。
CAN總線以報文為單位進行信息傳送，它支持4種不同類型的報文幀：數(shù)據(jù)幀、遠程幀、超載幀和錯誤幀。報文中包含信息標識符ID，它標志了報文的優(yōu)先權。CAN總線上各個節(jié)點都可主動發(fā)送，總線上的報文采用標識符ID進行仲裁，ID值越小，優(yōu)先級越高。具有最高優(yōu)先權報文的節(jié)點贏得總線使用權，而其它節(jié)點自動停比發(fā)送。在總線再次空閑后，這些節(jié)點將自動重發(fā)原報文。網絡中的所有節(jié)點都可由ID來自動決定是否接收該報文。每個節(jié)點都有ID寄存器和屏蔽寄存器接收到的報文只有與該屏蔽的功能相同時，該節(jié)點才開始正式接收報文，否則它將不理睬ID后面的報文。這使CAN系統(tǒng)非常靈活，可任意擴展或改變網絡組成。
C8051F系列單片機是集成的混合信號片上系統(tǒng)SOC（System on chip），具有與MCS-51內核及指令集完全兼容的微控制器，除具有標準8051的數(shù)字外設部件之外，片內還集成數(shù)據(jù)采集和控制系統(tǒng)中常用的模擬部件和其它數(shù)字外設及功能部件。正是由于其體積小、集成度高、功能多、配置容易、使用方便等特點，已被廣泛應用于智能儀表、數(shù)據(jù)采集、自動化控制等領域。因此本文采用C8051F120設計與實現(xiàn)CAN總線通信協(xié)議，充分發(fā)揮其體積小、可靠性高的特點。C8051F120是完全集成的混合信號片上系統(tǒng)MCU芯片，具有64個數(shù)字I/O引腳（100腳TQFP封裝）。
2 數(shù)據(jù)傳輸格式的制定
在CAN2.0規(guī)范中規(guī)定，每次收發(fā)最多只能傳送8字節(jié).這可以滿足大多數(shù)工業(yè)領域中控制命令、工控狀態(tài)和測試數(shù)據(jù)的一般要求；但實際應用中，往往出現(xiàn)傳送多于8字節(jié)的要求，此時應通過報文的拆卸和拼接技術予以實現(xiàn)。本文在CAN2.0A的基礎上，定義了簡單的傳輸格式，完成了單幀數(shù)據(jù)和多幀數(shù)據(jù)準確快捷的傳輸。
信息傳遞格式如表一所示:
500)this.style.width=500;" border="0" />

其中，各位的含義如下：
FF:0表示為標準格式，1表示為擴展格式；
RTR:0表示為數(shù)據(jù)幀，1表示為遠程幀；
DLC.X:數(shù)據(jù)長度代碼位（0～8）；
ID.X:信息標識符位:
ID.28～ID.26為信息功能標識
    ID.25～ID.21為接收任務標識
    ID.20～ID.18為接收節(jié)點地址標識
X :保留位，默認為0，不能對保留位進行寫操作；
DATAO:數(shù)據(jù)場的第一個字節(jié)，本協(xié)議中用來表明數(shù)據(jù)的屬性；
DATA0.7～DATAO.5為發(fā)送節(jié)點地址標識；
DATA0.4～DATAO.1為數(shù)據(jù)功能標識
    DATA0.0 0為擴展位，‘0’ 表明數(shù)據(jù)長度小于8不用擴展，‘1’ 表示數(shù)據(jù)長度大于8需要擴展DATA1作傳遞次數(shù)索引。
 DATA1: DATAO.0為0時，傳遞數(shù)據(jù)；DATAO.0為1時，為數(shù)據(jù)傳遞次數(shù)的索引。
本文設計的信息優(yōu)先級從高到低依次為:信息功能標識、任務功能標識和目標節(jié)點地址標識。信息功能標識設在ID的最高幾位，通過3位的功能代碼可以區(qū)分某些情況的8種基本功能:這些功能可以為節(jié)點狀態(tài)控制、節(jié)點保護、緊急情況通報以及有時間標記的信息等；接收任務標識表明本幀數(shù)據(jù)的任務屬性，容量為32；目標節(jié)點地址指示本次數(shù)據(jù)的目的地址，容量為8。
DATA0.0在本協(xié)議中作為標志位，用來區(qū)別單幀傳輸和多幀傳輸，解決了大于8字節(jié)的字符串的傳輸問題。當標志位為1時，表示傳送的是多幀數(shù)據(jù)；為0時表明是單幀數(shù)據(jù)。這樣克服了CAN 只能傳輸小于等于8字節(jié)數(shù)據(jù)的缺點，實現(xiàn)了大于8字節(jié)的數(shù)據(jù)的傳輸。
為了識別多幀傳輸中可能會出現(xiàn)的重幀和丟幀現(xiàn)象，本協(xié)議規(guī)定數(shù)據(jù)場第一字節(jié)作為多幀數(shù)據(jù)傳輸次序的索引。按照本協(xié)議制定的格式傳輸數(shù)據(jù)時，單幀最多傳輸7字節(jié)的實際數(shù)據(jù)：當數(shù)據(jù)流長度大于7字節(jié)時，就要分成多幀傳送。
3 應用層協(xié)議設計
在CANV2.0規(guī)范標準中，只規(guī)定了ISO參考模型的物理層和數(shù)據(jù)鏈路層，沒有規(guī)定媒體的連接單元以及駐留媒體，也沒有規(guī)定應用層。物理層負責譬如物理信號傳輸、譯碼、位時序和位同步等功能，而數(shù)據(jù)鏈路層負責總線仲裁、信息分段以及數(shù)據(jù)安全、數(shù)據(jù)確認、錯誤檢測、信號傳輸和錯誤控制的功能。實際上，即使在執(zhí)行一些非常簡單的基于CAN的分布式系統(tǒng)時。除了基本的兩層服務之外，還要求或希望有更多功能，如發(fā)送長于8字節(jié)的字符串、響應或確定數(shù)據(jù)傳送、標識符分配、網絡啟動或監(jiān)控節(jié)點。
由于這些附加的功能直接支持應用過程，所以它可以被認作“應用層”。如果正確執(zhí)行，則應用層以及相應的應用層接口（子協(xié)議）為通訊和應用過程提供了一個清晰定義的分界以便把它們區(qū)分開來。在一些利用簡單的通信協(xié)議就可以滿足要求的情況下，采用復雜的協(xié)議會造成資源的浪費，而且，使用起來也很不方便，反而限制了CAN的靈活性。所以在一些情況下制定適合要求的通信協(xié)議，對CAN的開發(fā)和使用至關重要。本文根據(jù)實際系統(tǒng)設計的需要，在2.0A技術規(guī)范的基礎上制定了CAN應用層通信協(xié)議。
CAN應用層協(xié)議主要負責建立CPU與底層之間的橋梁，它主要由四部分組成：節(jié)點的開關機制、數(shù)據(jù)的收發(fā)機制、錯誤處理機制和中斷管理機制五部分組成。四種機制互相聯(lián)系、互相制約，共同維護系統(tǒng)的運轉。限于篇幅本文主要介紹關鍵的數(shù)據(jù)收發(fā)機制。
3.1 數(shù)據(jù)發(fā)送機制
發(fā)送機制主要實現(xiàn)將CPU要發(fā)送的數(shù)據(jù)接過來，并整理為符合應用層協(xié)議規(guī)定的幀格式，將拆卸好的小包（數(shù)據(jù)幀）順序放入循環(huán)隊列中等待發(fā)送，并負責管理和維護發(fā)送循環(huán)隊列的止常運轉。在定時器定時中斷中定期對循環(huán)隊列進行掃描，如果發(fā)現(xiàn)隊列中有數(shù)據(jù)等待發(fā)送，則調用發(fā)送函數(shù)將數(shù)據(jù)發(fā)送到CAN總線。
在底層開辟了一個臨時緩沖區(qū)用于暫時存放等待發(fā)送的小包，臨時緩沖區(qū)采用循環(huán)隊列的存儲結構，對數(shù)據(jù)實行先入先出的管理模式。循環(huán)隊列是一個42*11的二維數(shù)組，用來暫時安置CPU即將發(fā)送的數(shù)據(jù)，數(shù)據(jù)被順序安排在循環(huán)隊列中等待發(fā)送。每增加一幀數(shù)據(jù)，循環(huán)隊列的尾指針加1；每成功發(fā)送完一幀數(shù)據(jù)，循環(huán)隊列的頭指針減1。當循環(huán)隊列中沒有數(shù)據(jù)時，隊列的狀態(tài)為空，否則指示為不空；若循環(huán)隊列的頭指針和尾指針重合而隊列又處于不空的狀態(tài)，此時隊列為滿的狀態(tài)。當隊列處于滿的狀態(tài)時，禁止向隊列再寫入數(shù)據(jù)，否則容易導致數(shù)據(jù)的覆蓋或丟失。隊列中數(shù)據(jù)遵循先入先出的原則，CPU將數(shù)據(jù)從隊列尾部裝入，向CAN總線發(fā)送數(shù)據(jù)時則從隊列頭部將數(shù)據(jù)讀走。發(fā)送循環(huán)隊列的曾理單位為幀，每次操作都是11個字節(jié)為單位。在發(fā)送機制運轉前，首先對發(fā)送循環(huán)隊列初始化，將循環(huán)隊列的頭指針、尾指針賦值為零，將已占用的空間也賦值為零。
CAN發(fā)送機制主要由兩大模塊組成：打小包模塊和幀發(fā)送模塊。當CPU有數(shù)據(jù)需要發(fā)送時，調用打小包函數(shù)，要求給出待發(fā)送數(shù)據(jù)的存放地址。打小包函數(shù)將會按照本協(xié)議規(guī)定的格式將發(fā)送節(jié)點地址、接收節(jié)點地址、信息類型、任務標識、數(shù)據(jù)標識等參數(shù)整理為CAN數(shù)據(jù)鏈路層ID的格式，將數(shù)據(jù)組裝成符合應用層協(xié)議所規(guī)定的數(shù)據(jù)幀（小包），實現(xiàn)對長度大于7字節(jié)的數(shù)據(jù)的打小包處理，按照所填加索引號的順序放到發(fā)送循環(huán)隊列中等待發(fā)送。打小包函數(shù)的流程圖如圖1所示：
500)this.style.width=500;" border="0" />

3.2 數(shù)據(jù)接收機制
CAN接收機制負責將數(shù)據(jù)從CAN總線上接收下來，按照數(shù)據(jù)源節(jié)點的地址將其還原為發(fā)送前的格式，準確無誤的傳遞給上層，并負責為上層提供接口函數(shù)。在CPU將數(shù)據(jù)取走以后，清空相應的數(shù)組。
在底層開辟了一個臨時緩沖區(qū)用于暫時存放從CAN總線上接收下的數(shù)據(jù)，臨時緩沖區(qū)采用二維數(shù)組的格式，容量為4*3*64。第一維的容量為4，分別指示發(fā)送節(jié)點的地址；第二維容量為3，作為數(shù)據(jù)的擴展緩存，指示可連續(xù)存放來自于同一節(jié)點的包的數(shù)目；第三維的容量為64，用來存放經過整理以后的數(shù)據(jù)。一般來說，開辟一個二維的空間就可以使協(xié)議周轉，但是，在實際系統(tǒng)中可能會出現(xiàn)CPU還未能將整理完畢的數(shù)據(jù)取走此時又接到來自于同一節(jié)點的新的數(shù)據(jù)，這樣就可能導致新的數(shù)據(jù)覆蓋掉原來的數(shù)據(jù)，造成數(shù)據(jù)的丟失。為避免這種潛在地危險，因此開辟了三維空間，在最壞的情況下，每個節(jié)點都可同時容納來自于同一節(jié)點連續(xù)發(fā)送的3包數(shù)據(jù)，大大降低了數(shù)據(jù)丟失的可能性。接收數(shù)據(jù)流程如圖二所示。
500)this.style.width=500;" border="0" />

圖 二： 數(shù)據(jù)發(fā)送流程
5  總結
本文創(chuàng)新點：CAN總線以其卓越的特性、極高的可靠性和獨特的設計，在工業(yè)過程監(jiān)控設備的互聯(lián)方面得到廣泛的應用，受到工業(yè)界的廣泛重視，并被公認為是最有前途的現(xiàn)場總線之一。作為通用、有效、可靠及經濟的平臺，CA N協(xié)議也已經廣泛地受到了歡迎。由于CAN2.0規(guī)范固有的局限性，客觀上要求用戶建立高層協(xié)議對CAN進行完善。本文所設計的CAN總線應用層協(xié)議已經投入使用，具有簡單、靈活、移植方便等特點。