CAN通信的數據幀和遠程幀

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

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

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

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

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

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

總結（以下內容轉載自allen6268198的博客）：
由於CAN總線發送幀時，仲裁方法只依靠幀ID號，當有兩個相同ID號的幀同時競爭總線時，總線就無法判別出讓哪個設備先發送幀，於是就造成總線衝突。

爲了總線訪問安全，每個發送器必須用獨屬於自己的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的過濾器已在發送遠程幀之前做了相應設置）。由此可見，遠程幀可以使請求更簡單，但也非不可代替。