CAN通訊的數據幀和遠程幀

（先來一波操做，再放概念）
遠程幀和數據幀很是類似，不一樣之處在於：
（1）RTR位，數據幀爲0，遠程幀爲1；
（2）遠程幀由6個場組成：幀起始，仲裁場，控制場，CRC場，應答場，幀結束，比數據幀少了數據場。
（3）遠程幀發送特定的CAN ID，而後對應的ID的CAN節點收到遠程幀以後，自動返回一個數據幀。web

環回模式下（方便調試用），設置爲發送遠程幀：
STM32端經過J-Link RTT調試軟件能夠打印出CAN接收到數據（在中斷服務函數裏面接收）；
而經過CANTest軟件不能接收到STM32端發送出來的數據，由於遠程幀比數據幀少了數據場；
安全

正常模式下：經過CANTest軟件手動發送一組數據，STM32端經過J-Link RTT調試軟件也能夠打印出CAN接收到的數據；
svg

附上正常模式下，發送數據幀的顯示效果：
函數

接下來是概念
看完上文，能夠簡單理解爲：
若是A須要B節點向你發送數據！A能夠用B節點的ID，發送一個Remote frame（遠程幀），B收到A ID 的 Remote Frame 以後就發送數據給A！發送的數據就是數據幀！
遠程幀就像命令,命令相應的節點返回一個數據包.調試

應用（劃重點）：若是須要CAN上某個節點向你發送數據，你能夠用這個節點的ID，發送一個Remote frame（遠程幀），這樣節點接收到這個Remote frame以後會自動發送數據給你！發送的數據就是數據幀！
主要用來請求某個指定節點發送數據，並且避免總線衝突。xml

總結（如下內容轉載自allen6268198的博客）：
因爲CAN總線發送幀時，仲裁方法只依靠幀ID號，當有兩個相同ID號的幀同時競爭總線時，總線就沒法判別出讓哪一個設備先發送幀，因而就形成總線衝突。blog

爲了總線訪問安全，每一個發送器必須用獨屬於本身的ID號往外發送幀(多個接收器的過濾器ID能夠重複)，（可讓某種信號幀只使用特定的ID號，而每一個設備都是某一種信號的檢測源，這樣就造成某一特定個設備都只是用特定的ID號往總線上發送數據)。圖片

設有設備A，B，且假設A發送信息的ID爲A_ID=1，B發送信息時是用的ID爲B_ID=2。
A是收取溫度信息的設備，B是採集溫度信息的設備。
某一時刻，A須要請求B發送溫度信息幀。那麼A可有2種方法發送請求：
1）A發送一幀數據，ID號爲B的ID號(B_ID),數據域內容爲【請求溫度信息】。
B的過濾器設置爲接收B_ID幀。
則A發送後被B接收到，B再以B_ID發送溫度信息幀。被A接收到。
這看似完美的過程，其實存在可能的總線衝突：若是A發送幀的同時，B也正要往總線上發送溫度幀，則形成總線衝突。
固然也能夠採用別的方法來解決此問題，如A發送請求溫度幀的ID號改爲別的，固然B的過濾器也要作相應的設置。
2）使用遠程幀來作信息請求:因爲A直接發送B_ID號的數據幀，可能形成總線衝突，但如果A發送遠程幀：遠程幀的ID號天然是B發送幀使用的ID號（B_ID )。
因爲CAN總線仲裁時，數據幀發送的優先級高於遠程幀，即便有別的節點設備也在發送以B_ID爲ID號的遠程幀，由於遠程幀除了ID號不一樣，其餘都相同。因此不會形成總線衝突。
當B（前提是以對過濾器設置接受B_ID類型的幀)接受到遠程幀後，在軟件（注意，是在軟件的控制下，而不是硬件自動迴應遠程幀）控制下，往CAN總線上發送一溫度信息幀，即便用B_ID做幀ID號往CAN總線上發送溫度信息幀。該幀被A接受到（固然A的過濾器已在發送遠程幀以前作了相應設置）。因而可知，遠程幀可使請求更簡單，但也非不可代替。博客