- 1. Introduction
- 2. CAN Communication
- 3. CAN Framing
- 4. CAN Bus Access
- 5. CAN Data Protection
6. CAN FD
- Advantages and Consequences
- New Types of Frames
- Details of a CAN FD Frame
- Distinguishing CAN from CAN FD Frames
- Compatibility of CAN and CAN FD Controllers
- Accelerated Transmission
- Indicating too many Errors
- Length of the Data Field
- More Data with the same Security
- Changed Rules for Bit Stuffing and CRC Calculation
Besides the data frame used to transport data, there is the remote frame — a frame type used to request data, i.e. data frames, from any CAN node. Nonetheless, these frames are hardly ever used in automotive applications, since data transmission is not based on requesting, rather it is primarily based on the self-initiative of information producers. Remote frames may be transmitted in either standard or extended format.
Determination by RTR
Except for the lack of a data field, the layout of a remote frame identical to that of a data frame. Data and remote frames are differentiated by the RTR bit (Remote Transmission Request). In the case of a data frame, the RTR bit is sent as dominant. A remote frame is identified by a recessive RTR bit.
In principle, remote frames may be defined for all existing data frames in the CAN network. It is only necessary to ensure that the identifiers of the remote frames match those of the associated data frames. The ECU responsible for generating the desired data frame responds to a remote frame by sending it.
Remote frames and responses
In the case of a CAN controller with object storage, the CAN controller automatically responds to a remote frame. CAN controllers without object storage must let the host know about the remote frame so that it can initiate a response.
In the ideal case, the request by remote frame immediately leads to a response with the relevant data frame. However, it may occur that CAN messages with higher priority may be inserted between request and response.