Data frame and remote frame of CAN communication

(Come first, then put the concept)
The remote frame is very similar to the data frame, the difference is:
(1) RTR bit, the data frame is 0, and the remote frame is 1;
(2) The remote frame consists of 6 fields: frame start, arbitration field, control field, CRC field, response field, frame end, which is less data field than data frame.
(3) The remote frame sends a specific CAN ID, and then the corresponding ID CAN node automatically returns a data frame after receiving the remote frame.

In loopback mode (convenient for debugging), set to send remote frame:
The STM32 side can print out the data received by CAN through the J-Link RTT debugging software (received in the interrupt service function);
The data sent by the STM32 terminal cannot be received through the CANTest software, because the remote frame has less data fields than the data frame;

In normal mode: manually send a set of data through CANTest software, STM32 can also print out the data received by CAN through J-Link RTT debugging software;

Attach the display effect of sending data frame in normal mode:

Concept

After reading the above, it can be simply understood as:
If A needs node B to send data to you!A can use the ID of node B to send a Remote frame (remote frame), and B will send data to A after receiving the Remote Frame of A ID!The data sent is the data frame!
A remote frame is like a command, instructing the corresponding node to return a data packet.

Application (emphasis): If you need a node on CAN to send data to you, you can use the ID of this node to send a Remote frame (remote frame), so that the node receives thisAfter the Remote frame will automatically send data to you!The data sent is the data frame!
It is mainly used to request a specified node to send data and avoid bus conflict.

Summary

     Since the CAN bus sends frames, the arbitration method only relies on the frame ID number. When there are two frames with the same ID number competing for the bus at the same time, the bus cannot determine which device should send the frame first, thus causing the busconflict.

     For bus access security, Each transmitter must use its own ID number to send out frames (multiple receiver filter IDs can be repeated), (can make a certain signal frameOnly use a specific ID number, and each device is the detection source of a certain signal, so that a specific device only sends data to the bus with a specific ID number).

There are devices A and B, and it is assumed that the ID of A sending information is A_ID=1, and the ID used by B to send information is B_ID=2.
A is a device that collects temperature information, and B is a device that collects temperature information.

At a certain moment, A needs to request B to send a temperature information frame.Then A can send the request in two ways:

(1) A sends a frame of data, the ID number is the ID number (B_ID) of B, and the content of the data field is [Request temperature information].
B's filter is set to receive B_ID frames.

After A sends it, it is received by B, and B sends the temperature information frame with B_ID.received by A.
This seems to be a perfect process, but there is actually a possible bus conflict: if A is sending a frame at the same time, B is also sending a temperature frame to the bus, which will cause a bus conflict.

Of course, other methods can also be used to solve this problem, such as changing the ID number of the temperature frame sent by A to something else, and of course, the filter of B should also be set accordingly.

(2) Use the remote frame for information request: Since A directly sends the data frame of B_ID number, it may cause a bus conflict, but if A sends a remote frame: the ID number of the remote frame is naturally the ID number used by B to send the frame(B_ID).

Due to the CAN bus arbitration, the priority of sending data frames is higher than that of remote frames, even if other node devices are sending remote frames with B_ID as the ID number, because the remote frames are the same except for the ID number.So there will be no bus conflict.

When B (provided that the filter is set to accept the frame of type B_ID) receives the remote frame, under the control of the software (note that it is under the control of the software, not the hardware automatically responds to the remote frame), go to the CANSend a temperature information frame on the bus, that is, use B_ID as the frame ID number to send the temperature information frame to the CAN bus.The frame is received by A (of course A's filter has been set accordingly before sending the remote frame).It can be seen that remote frames can make requests simpler, but they are also irreplaceable.