- 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
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
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.