基于CAN總線通信協(xié)議的設計與實現(xiàn)
加入技術交流群
本文設計的信息優(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所示：
評論