Implementations of the CAN protocol

Communication is identical for all implementations of the CAN protocol. There are differences, however, with regard to the extent to which the implementation takes over message transmission from the microcontroller which follow in the circuit.

CAN controller with intermediate buffer

CAN controllers with intermediate buffer (formerly called basicCAN chips) have implemented the logic as hardware which is necessary to create and verify the bitstream according to the protocol. However, the administration of data sets to be sent and received, acceptance filtering in particular, is carried out by the CAN controller only to a limited extent.

Typically, CAN controllers with intermediate buffer have two reception and one transmission buffer. The 8-bit code and mask registers allow a limited acceptance filtering (8 MSB of the identifier). Suitable choice of these register values allows groups of identifiers or in borderline cases all IDs to be selected. If more than the 8 ID-MSBs are necessary to differentiate between messages then the microcontroller following the CAN controller in the circuit must complement acceptance filtering by software. CAN controllers with intermediate buffer may place a strain on the micro-controller with the acceptance filtering, but they require only a small chip area and can therefore be produced at lower cost. In principle they can accept all objects in a CAN network.

CAN controller with object storage

Message frame for standard format (CAN Specification 2.0A)
Message frame for standard format (CAN Specification 2.0A)

CAN objects consist mainly of three components:

  • identifier (ID)
  • data length (DLC)
  • useful data

CAN controllers with object storage (formerly called FullCAN) function like CAN controllers with intermediate buffers, but also administer certain objects. While there are several simultaneous requests they determine, for example, which object is to be transmitted first. They also carry out acceptance filtering for incoming objects. The interface to the following microcontroller corresponds to a RAM. Data to be transmitted are written into the appropriate RAM area, data received are read out correspondingly. The microcontroller has to administer only a few bits (e. g. transmission request).

CAN controllers with object storage are designed to take as much strain as possible off the local microcontroller. These CAN controllers require a greater chip area, however, and therefore are more expensive. In addition to this, they can only administer a limited number of chips.

Image: Physical CAN Connection according to ISO 11898
Physical CAN Connection according to ISO 11898

Now CAN controllers are available which combine both principles of implementation. They have object storage, with at least one that is designed as an intermediate buffer. For this there is no reason to differentiate between basicCAN and fullCAN any longer.

CAN slave controllers for I/O functions

As well as CAN controllers which support all functions of the CAN protocol there are also CAN chips which do not require a following microcontroller. These CAN chips are called SLIO (serial link I/O). CAN chips are CAN slaves and have to be administered by a CAN master.

Physical CAN connection

Data rates (up to 1 Mbit/s) necessitate a sufficiently steep pulse slope, which can be implemented only by using power elements. A number of physical connections are basically possible. However, the users and manufacturers group CAN in Automation recommends the use of driver circuits in accordance with ISO 11898. Integrated driver chips in accordance with ISO 11898 are available from several companies (Bosch, NXP, Siliconix and Texas Instruments). The international users and manufacturers group (CiA) also specifies several mechanical connections (cable and connectors).