SNIP_CLASSIC_CAN_SECTION_7_5_L_PDU_transmission

7.5 L-PDU transmission On L-PDU transmission, the Can module converts the L-PDU contents ID and Data Length to a hardware specific format (if necessary) and triggers the transmission. [SWS_Can_00059] ⌈Data mapping by CAN to memory is defined in a way that the CAN data byte which is sent out first is array element 0, the CAN data byte which is sent out last is array element 7 or 63 in case of CAN FD.⌋(SRS_SPAL_12063) [SWS_Can_00427] ⌈If the presentation inside the CAN Hardware buffer differs from AUTOSAR definition, the Can module must provide an adapted SDU-Buffer for the upper layers.⌋() [SWS_Can_00100] ⌈Several TX hardware objects with unique HTHs may be configured. The CanIf module provides the HTH as parameter of the TX request. See Figure 7.3 for a possible configuration.⌋(SRS_Can_01135) Figure 7.3: Example of assignment of HTHs and HRHs to the Hardware Objects. The numbering of HTHs and HRHs are implementation specific. The chosen numbering is only an example. [SWS_Can_00276] ⌈The function Can_Write shall store the swPduHandle that is given inside the parameter PduInfo until the Can module calls the CanIf_TxConfirmation for this request where the swPduHandle is given as parameter.⌋() The feature of [SWS_Can_00276] is used to reduce time for searching in the CanIf module implementation. [SWS_Can_00016] ⌈The Can module shall call CanIf_TxConfirmation to indicate a successful transmission. It shall either called by the TX-interrupt service routine of the corresponding HW resource or inside the Can_MainFunction_Write in case of polling mode.⌋(SRS_Can_01051)