SNIP_CLASSIC_CANIF_SECTION_7_26_CAN_FD_Support

7.26 CAN FD Support For performance reasons some CAN Controllers allow to use a Flexible Data-Rate feature called CAN FD (see [12, ISO 11898-1:2015]). Besides, the higher baud rate for the payload CAN FD also supports an extended payload which allows the transmission of up to 64 bytes. If these features are available depends on the general CAN FD support by the CAN Controller and if the CAN Controller is in CAN FD mode (valid CanControllerFdBaudrateConfig). If an L-SDU shall be sent as CAN FD or conventional CAN 2.0 frame depends on the second most significant bit of the configured CanIfTxPduCanId. CanIf indicates this to CanDrv utilizing the same bit of PduInfo->id (Can_IdType) passed while calling Can_Write(). Note: If CanDrv is not in CAN FD mode (no CanControllerFdBaudrateConfig), the L-PDU will be sent as conventional CAN 2.0 frame as long as the SduLength <= 8 bytes. Note: The arbitration phase of conventional CAN 2.0 frames and CAN FD frames does not differ if the same CanId is used. Therefore, even when using CAN FD frames each CanId must not be used more than once. Which kind of frame was received by CanDrv is also indicated utilizing the second most significant bit of the Can_IdType passed with CanIf_RxIndication() (Mailbox- >CanId). Based on this information CanIf decides how to map to the configured L-SDU (CanIfRxPduCfg) as described in [SWS_CANIF_00877]. Note: If upper layers don’t care if a message was received by conventional CAN 2.0 frame or CAN FD frame, it is possible to use only one CanIfRxPduCfg for both types (using the second most significant bit of CanIfRxPduCanIdMask). This might allow local optimization. However, from a system point of view, the format for each frame has to be configured. Otherwise the sender wouldn’t know which kind of frame shall be transmitted.