昨晚很榮幸邀請到李工在RT-Thread微信群進行RT-Thread上的CAN驅動和應用講座。小編整理了講座內容，特發出講義以供享用。

講師：李起偉，任職于煤炭科學技術研究院有限公司，助理研究員，碩士，現主要從事嵌入式系統與煤礦安全監測監控系統的研究工作

分享主題：RT-Thread上的CAN驅動和應用

大家晚上好，今天跟大家探討一下RTT上的CAN驅動和應用相關一些內容，主要有三個方面，第一項介紹一下CAN總線的基礎知識，主要是一些幀格式的介紹。第二項是RTT上的CAN驅動的一個編寫，這部分內容主要介紹一些CAN設備的讀和寫以及中斷處理函數的驅動編寫，中斷處理函數主要說一下接收部分的處理。最后一項就是介紹一下CAN數據的處理現場的編寫，整個內容都寫得比較淺，然后在咱們這個探討內容結束之后，我給大家發一個CAN總線的基礎教程，然后另外我寫的這部分驅動包括處理現場也是我在實際產品當中應用的，隨后我把這部分內容的代碼然后整理一下，之后也放出來。

我們就開始第一部分的內容，，說一下CAN的這個特性吧，在這個CAN的介紹當中會有跟這個modbus總線會有一些簡單的對比，那么CAN總線它是一個多主站的結構，在總線上掛的這個所有的節點，他們的節點地位都是平等的，就是所有的節點都可以向總線當中主動地發送數據，不需要等待其他的節點的就是跟他發命令說我才可以往上發，這一點是跟modbus的區別，就是說modbus總線，他是一主多從的，在總線上只有一個主節點，其他節點都是從機，從機只能被動地根據主機的命令做出相應的回復或者是動作，當然這些節點再往總線上發送數據的時候會有一個優先級的問題。

在CAN總線當中，它有一個種CAN總線仲裁的機制，它主要是通過報文ID來實現的，那么在CAN總線當中執行的是“線與”操作，0是屬于顯性電平，1是隱性電平。這樣的話進行限于之后報名ID越小，那么他在總線競爭當中優先級也就越高，報文ID或者說是這個標識符與這個節點的ID或者節點序號，這是兩個完全不同的概念，就是在這個報名ID當中其實可以包，因為它在擴展的幀當中有29位，可以包含很多有意義的內容，你都可以幫放在這個標識符當中。

在這個標識符當中，我們可以把發送節點的序號類型、接受節點的序號類型甚至安裝位置等一系列信息都包含在那里，所以說標識符它在一定程度上就描述數據的含義，這樣的話就在某些特定應用當中可以對標識符進行過濾，就是說我需要的我才接受，不需要的我就可以過濾掉，然后這樣的話CPU呢不需要進行參與一些操作，完全由CAN控制器就可以完成了。

modbus總線一些協議棧也可以對報文進行過濾，但是這是需要CPU進行參與的，這樣的話就會占用CPU，也就是說當modbus總線上有數據的時候，所有節點都是要參與的，這樣的話一旦modbus總線上有數據，所有的節點當前正在執行的任務都會被打斷，所以這樣的話也是CAN總線跟modbus總線的區別，或者是一點優勢吧。

因為CAN總線是是一種差分電平，所以它使用那個雙絞線作為它的總線傳輸介質，在1Mbps的情況下，總線長度一般會小于40米，我們看這個U線這張圖，從現在傳輸速率跟它的傳輸距離在一定程度上是成反比例關系的，而我們在實際應用當中，曾經做到過在5Kbps的情況下達到了7到8公里，而且還是一種多分叉多分枝這種結構。總線結構比較復雜，而不是我們通常見的一條總線或母線，節點都單獨的掛在這個總線路線上，在實際運用當中，這種情況其實很少見。

說一下CAN協議的版本，那么目前主要就是2.0B，是可以兼容11位和29位兩種ID的報文，就是說標準幀和擴展幀都可以兼容，具體的協議內容大家可以去查閱一下相關的文檔，這里就不再多說。

CAN總線當中主要的幀格式主要數據幀和遠程偵。數據幀也分兩種，就是標準幀和擴展幀，遠程偵同樣有對應的標準幀和擴展幀。

對這兩種幀格式來簡單地介紹一下，標準幀和擴展幀主要區別就是在幀ID的位數上，標準幀是11位ID，擴展幀是29位ID。我們看標準幀，它有一個隱性電平幀起始，之后是11位的幀ID，然后是一個RTR位，RTR位的意思是什么呢？遠程傳送請求位，那這位是0就是數據幀,1的話就代表遠程幀，顯性電平，也就是說數據幀的優先級要高于遠程幀，那么在進行總線仲裁的時候，數據幀獲得總線的控制權。用來區別標準幀和擴展幀的這位叫做標識符擴展位。0代表標準幀，1代表擴展幀。這樣的話，當標準幀和擴展幀在進行爭奪總線的時候，那肯定是標準幀獲得總線控制權。

DLC位代表數據長度，一共四位，有效值是0—8，9到15沒有效，他代表數據場，指后面的數據場里面一共有多少個字節能夠被傳送。再然后是15位CRC位，因為這個CRC校驗的起始是從幀開始一直到數據場的結束，整個這一串的位數參加這個CRC校驗。CRC檢驗完事之后是一個DR位，這位叫做CRC界定服務，到這里就表示CRC校驗完事了，后面就是應答場。對于我們這個用戶來說，在實際的編程應用當中，我們用戶一般的需要做的其實是仲裁場以及控制場和數據場，上其他的CRC場場、ASK場均結束。一般不需要用戶進行參與，這些都是由CAN控制器來自動完成的。

我們再來看擴展幀。擴展幀首先前面的11位幀ID先不，后面看RTR位后面。SR位與RTR位是在同一個位置上，RTR位叫做遠程傳送請求位，SR位叫做遠程請求替代位，后面的部分就跟標準一樣，這個就不再多。真正的RRT位被移送到了29位的幀ID的后面，那么SR位或者是RTR位在標準幀或者是在擴展幀當中，它也有高電平還是低電平。那么在標準幀當中同樣的位RTR一定是顯性電平，而在擴展幀當中這個一定是隱性電平。

再一下，遠程幀。遠程幀同樣分為兩種，就是根據這ID的位數不同，分為標準遠程幀和擴展遠程幀，我們看一下圖上的這個RTR位，在這他就是一個隱形電平，就明他是一個遠程幀， 遠程偵和數據幀的主要區別就是在于除了這個RTR位之外，還有一個區別遠程幀沒有數據場，是不帶數據的。

遠程偵在總線的主要作用是什么呢？就是我們知道CAN總線是多主的，就是大家都是平等的，向總線上各自發送數據，這個就像我們在微信群里聊天一樣，有人一直往這個群體方式發送一些消息。但是假如其中有人覺得你發送的消息不是我想要的，或者不滿足我的要求那么怎么辦呢？我就會主動給你請求數據，那么我就向你發送這個遠程偵那。至于你向誰請求數據、請求的是什么數據，那我可以都可以包含在幀ID當中，而且也只能包含在幀ID當中，因為這個遠程偵當中他沒有數據場，你所有的數據的意義只能在幀I當中，也基本上就相當于你的那個數據的個性化定制吧。

在這點與modbus的0X03和0X06呢比較類似，相當于取多個或單個寄存器的數據命令，指主動的索取數據。這條命令，舉一個應用的場合吧。比方在火災預警的場合，一般現實的過程當中鑒定火災的幾個要素：一個是溫度，一個是煙霧，另外一個是一氧化碳的濃度。煙霧傳感器、一氧化碳傳感器還有溫度傳感器，他們都是同樣掛在一條CAN主線當中，假如現在監測到煙霧傳感器煙霧濃度變大了，但是我們知道目前的煙霧傳感器有一個最大問題對水蒸氣特別敏感，即使水蒸氣濃度很高，煙霧傳感器就會誤報警。那么為了確認當前確實是煙霧傳感器誤報警，還是確實發生了火災，那么我們就要及時看到當前一氧化碳的濃度以及溫度的情況。這時候我可以主動發送一個遠程偵來索取一氧化碳傳感器的數據以及溫度傳感器的數據，通過這幾個傳感器的數據進行綜合的比較，或者是按照一定的算法，我們就可以知道現在是否確實發生了火災，還是煙霧傳感器進行了誤報警。這樣就可以防止一些不必要的誤報警，因為誤報警會有很多的問題。關于CAN的幀格式的一些介紹就簡單介紹到這里。

下面就進入到RT-Thread上的CAN驅動的編寫部分，一些剛接觸到RTT的一些朋友，可能覺得這個學這個驅動比較困難，或者是不知道無從下手。

其實你看一下就是RTT上面現有的一些設備的驅動，比方串口的、SPI的等等一些現有設備的驅動，仔細揣摩一下，自帶這個驅動都寫得很規范，大家可以完全可以借鑒和模仿，那么這個驅動其實主要實現在這個圖片上列出來這七個函數，我們能把這些函數都實現了，并且把設備注冊到這個系統內核當中，這個設備的驅動也就基本完成。我今天講的這個CAN的驅動是在1.2.3版本的串口驅動上改寫的，當時的這個串口驅動跟現在還是有很大區別的，一會大家可以看一下。