CAN protocol implementations

In the early days, the CAN data link layer protocol was implemented in stand-alone controllers (e.g. 82526 by Intel or 80C200 by Philips Semiconductors). Today, there are just a few CAN stand-alone controllers on the market. Most CAN modules are integrated into host controllers (mainly micro-controllers). CAN modules are also available as IP (intellectual property) cores to be integrated into ASICs (application-specific integrated circuits). Another class of implementation is a single-chip solution comprising besides the CAN core and the micro-controller the CAN transceiver. More information on currently available CAN controllers respectively micro-controllers with on-chip CAN modules and IP cores can be found at the CAN Newsletter Online.

Frame format support

All CAN modules compliant with ISO 11898-1:2015 need to support the Classical CAN protocol. This means that they can receive and transmit the CAN base and the CAN extended frames. The reception and transmission of CAN FD frames is optional. Another allowed implementation option is tolerating the reception of CAN FD frames (not FD enabled), but it seems that this in not the favorite option. Implementations of Classical CAN that do not support 29-bit identifiers (formerly known as CAN 2.0A) or just tolerate extended frame formats (formerly known as CAN 2.0B passive) are not allowed anymore. CAN 2.0B passive nodes were compliant with ISO 11898-1:2003, but very rarely used.

Acceptance filtering and message buffers

Although the CAN interface (RxD and TxD) is well standardized, CAN modules behave dissimilar regarding acceptance filtering and the storing of received messages. Also, the scheduling of messages to be transmitted can be implemented in different ways. Some modern implementations provide configurable filtering, storing, and scheduling behavior.

The acceptance filtering of received messages can be done mainly through the software running on the host controller. However, this would cause a lot of interrupts that need to be processed. The software has to evaluate if a message is of interest or not depending on the CAN-ID. To unburden the host controller from this task, the CAN controller often provides a configurable hardware acceptance filter. There are two configuration registers: one indicates if the CAN-ID bit has to be considered; the second provides the pass condition (dominant or recessive) for each CAN-ID bit. Some implementations also filter the first or second data byte. This is important for some higher-layer protocols, which extend the content addressing to a part of the payload. Some implementations provide multiple acceptance filters.

There have to be at least two receive message buffers. They are used in a ping-pong-like procedure: When the host controller reads the first received message, the second is used to capture the next accepted message. However, if your host-controller is slow and there is a burst of accepted messages, the risk of loosing a frame is high. Therefore, often a single FIFO (first-in, first-out) receive buffer or multiple receive buffers are implemented.

On the transmitting site, a minimum of three buffers is necessary to avoid the inner priority inversion. This means that a message can't get bus access due to its low priority and even the highest priority message with a later transmission request has to wait until the low-priority message has been transmitted. Therefore, an internal arbiter in the CAN module is needed to bypass so-to-speak the earlier lower-prior message. Several CAN modules feature multiple transmit buffers scheduled by round-robin method or by priority.

Additional CAN module functions

Some CAN protocol implementations offer optional functions. These include, for example, the single-shot transmission of data frames. This means that the automatic re-transmission in case of detected errors is disabled. This is useful for TTCAN add-ons and some tool applications.

Another option is the bus-monitoring mode: The node can receive data and remote frames, but doesn’t acknowledge them and also doesn’t send error and overload flags. Nevertheless, these dominant bits are communicated internally in the CAN module. In the optional restricted operation mode, the CAN module behaves equally, but it acknowledges received data and remote frames. The error counters are not incremented and decremented in this mode. If a node is the TTCAN time master, it must be able to transmit the time-reference message; other frames must not be transmitted.

For some applications, message time stamping is required. ISO 11898-1:2015 specifies that the optional time-stamp function features resolutions of 8 bit, 16 bit, or 32 bit. The time-base value is captured at the reference point of each data frame and it is readable after EOF (end-of-frame). Other (not standardized) optional functions include readable error counters, configurable warning limits, interrupt request generation, and arbitration lost capture.

If the CAN implementation allows changing the configuration of a node by software, the configuration data (e.g. bit-time configuration or operating mode) needs to be locked against changes while CAN communication is ongoing.

Multiple CAN interface and bridge/switch functions

Many micro-controllers feature multiple CAN on-chip modules. Some of them provide additional bridge/switch hardware. This add-on function allows storing intermediately messages, so that the independent CAN ports can use different bit-rates. Additionally, you can route messages to dedicated ports depending on the CAN-ID. Such implementations are suitable for router and gateway devices. They can also be used for applications with redundant CAN networks.