Higher Level Protocols - CAN System Engineering - page 204

to the correct interface function. In this example, it is called the CanIf_Transmit
function .

CanIf_Transmit(CanTxPduId, &pPduInfoPtr);

4.2.3.7 CAN Interface

The CAN interface is the last hardware-independent module in the AUTOSAR-layered
architecture; it has the job to connect the hardware-dependent CAN driver. The CAN
interface gets the PDUs from the above layers, adds the data the CAN driver needs
and implements buffering functions (if the hardware is occupied) and acknowledge-
ment functions for the send and receive signalling. Furthermore, the CAN interface
controls the operating modes of the CAN controller (sleep mode and error modes) and
signals changes of these modes to the higher layers (wake-up and bus-off).
The function CanIf_Transmit , which is called by the PDU router, takes the cor-
responding configuration for the given PduId and calls the CAN driver. The mini-
mal configuration-related information is, for example, on which CAN channel the
message shall be sent and which CAN ID shall be used. After assembling these
data the driver function is called. It is possible that the CAN interface is able to call
several drivers—e.g. if an external CAN module is used. In general, the on-chip
CAN modules will be supported by one single CAN driver; hence, the use case with
several CAN drivers is rare. The CAN driver function gets as parameter the unique
hardware transmit handle ( Hth ) and a pointer to the data structure PduInfo , where
the CAN ID, DLC and a pointer to the payload data are stored.

Can_Write(CanIf_CTxPdus[txPduIndex].hth, &canPduInfo);

4.2.3.8 CAN Driver

The CAN driver is the last piece of the communication path of an AUTOSAR com-
pliant software platform. The driver initializes the register of the CAN module with
correct values and sets the right bits for actions or data transfer. The access to these
control and data registers will be provided by standardized functions to the higher
software layers. Another important functionality is the implementation of all inter-
rupt service routines Receive (Rx), Transmit (Tx), error, etc.). The driver receives
the data to be transmitted by the CAN interface, copies it into a hardware-mailbox
of the CAN controller and triggers the sending process. In the opposite direction,
the CAN driver signals the reception of a new CAN message via callback mecha-
nism, e.g. triggered by the receive interrupt.
Today's CAN controller provides complex, intelligent mechanisms implemented
in hardware, for example, FIFO buffering or filtering mechanisms. Universal drivers,
easy to port and maintainable on various hardware platforms, use these hardware func-
tions not very often. For example, FIFO buffering implemented in software is not effi-