Since it was introduced in the 1980s, the controller-area network (CAN) has evolved tremendously. Its extended capabilities have led to its wide adoption across applications, from automotive to industrial machine and factory automation. With this growth, complexity of implementation has also increased on two levels:
• CAN controller design has gone from a basic controller to a full CAN controller and, in some cases, an extended full CAN controller.
• CAN software stacks vary, from an automotive communication stack to CANOpen and DeviceNet.
Given that CAN is only a single component within the automotive system, developers need to be able to implement it with as few challenges as possible so they can focus on system-level functionality rather than struggle with peripheral configuration. This article will explore the CAN interface and discuss different ways of implementing, configuring, and tuning interfaces that simplify design.
A little CAN history
CAN was first introduced by Robert Bosch GmbH to address the growing complexity of vehicle functions and networks. In the early days of embedded systems development, modules contained a single microcontroller unit (MCU) performing a single or multiple simple functions, such as reading a sensor level via an analog-to-digital converter (ADC) and controlling a DC motor, as shown in Figure 1 . As these functions became more complex, designers adopted distributed module architecture, implementing functions in two or more MCUs on the same printed circuit board and using I2 C (inter-integrated circuit) or System Packet Interface (SPI) protocols to communicate between these functions. Continuing with the DC motor example, a complex module would have the main MCU performing all system functions, diagnostics, and fail-safe, while another MCU handles a brushless DC (BLDC) motor control function. This was made possible with the wide availability of general purpose MCUs at a low cost.
In today's vehicles, as functions become distributed within a vehicle rather than a module, the need for a high fault tolerance, inter-module communication protocol led to the design and introduction of CAN in the automotive market.
By the mid-1990s, CAN had seen wider adoption beyond automotive applications, venturing into industrial controls with the introduction of DeviceNet and CANOpen protocols.
With this traction in the market, many MCU suppliers have integrated a CAN controller as an integrated peripheral to address these markets. Although at a high level, CAN might seem similar in function to I2 C or SPI, allowing communication between two nodes, CAN's communication is fundamentally different at the controller level, offering the services listed:
• CAN communication is message based, not address based.
• A CAN node can send or request a message on the bus.
• CAN provides complex error handling.
• Up to five corrupted bits in a row can be detected with CRC-15 protection.
Being message based versus address based, a node on the CAN bus could own multiple messages for transmission. For example, a brake module might have a message containing vehicle-speed information, a message containing sensor information from wheel-speed sensors, and a message containing the diagnostics information, the latter having the highest transmit priority.
At first look, one might think that with all those message priorities and message ID decoding in a node, CAN would create a high load on the CPU, preventing additional more complex functions from being integrated. This issue is addressed by different types of CAN controllers also shows in Figure 2 .
• Basic CAN controller: A basic CAN controller povides very basic filtering implemented in the CAN controller hardware, with reduced message handling, leading to a high CPU load. In a basic CAN controller, the CPU would receive multiple interrupts from the CAN controller in order to receive, acknowledge, and parse a message, and from the application side, decide whether or not a response should be transmitted based on the ID of the received message. Basic CAN controllers should only be used in low baud-rate and low message-count communications, allowing the CPU to handle additional noncommunication tasks.
• Full CAN controller: A full CAN controller provides an extensive implementation of message filtering, as well as message parsing in the hardware, thus releasing the CPU from the task of having to respond to every received message. Full CAN controllers can be configured to interrupt the CPU with only those messages whose identifiers have been setup as acceptance filters in the controller. Full CAN controllers are also setup with multiple message objects referred to as mailboxes, which can store specific message information such as ID and data bytes received for the CPU to retrieve. The CPU, in this case, would retrieve the message any time but must complete the task prior to receiving an update of that same message and overwriting the current content of the mailbox. This scenario is resolved in the final type of CAN controllers.
• Extended full CAN controller: The extended full CAN controller provides an additional level of hardware-implemented functionality by using a hardware FIFO (first in, first out) for received messages. Such an implementation allows more than one instance of the same message to be stored before the CPU is interrupted, therefore preventing any information loss for high-frequency messages, or even allowing the CPU to focus on the main module function for a longer period of time.
It's also important to note that DeviceNet extends the filtering criteria beyond the ID field to the first two bytes of data, making a full or extended full CAN controller a must for implementing such a protocol.
Depending on the message architecture, the full and extended full configurations can coexist in a single module, in order to implement high-level message priority and improve received message handling for the CPU. For example, a module receiving fail-safe information in one message (for example, ID = 0x250) and temperature sensor information in another message (such as ID = 0x3FF) may configure the CAN controller as full for the first, and extended full with four buffer FIFO for the second: CPU is interrupted when each fail-safe message is received, and once every fourth temperature sensor message is received. Figure 3 illustrates such a CAN controller configuration with a visual CAN controller customizer for fast implementation of complex message-handling schemes where all three types of CAN controllers coexist:
• Message 5–Basic CAN mailbox.
• Message 0x250–Full CAN mailbox.
• Message 0x3FF–Extended full CAN mailbox.
In addition to its functional capabilities, CAN has been widely adopted for its high fault tolerance. With bit rates up to 1 Mbps, or bus length up to 1000m (at 50 Kbps), CAN bit timing must be implemented to allow functionality in an electrically noisy environment while maintaining a high level of failure detection and correction.
To guarantee a high level of fault tolerance, sub–bit-timing configuration has been introduced with CAN to allow tighter control of determining the correct bus state for each CAN bus.
A single CAN bit is represented by four segments:
• Sync_Seg : Used to synchronize the various nodes on the bus.
• Prop_Seg : Compensates for any physical delays (propagation delay on the physical bus and the internal CAN node.
• Phase_Seg1 , Phase_Seg2 : Used to compensate for phase edge errors. These segments are shortened or lengthened during resynchronization.
It's also common to find CAN controllers with only three segments, where the Prop_Seg time is added to the Phase_Seg1 time.
Figure 4 shows the bit-timing representation, with all parameters necessary for its implementation.
It's important to note that all CAN bit-timing calculations are based on time quanta (TQ) , defined as a fixed unit of time derived from the oscillator with a value between 8 and 25. In terms of time, a TQ is equivalent to as low as 1/25th bit or 40 ns for a 1-µs bit length at 1 Mbps bus speed.
As an overly simplified rule of CAN bit timing, the following list could be setup to govern the values of the 4-bit time segments:
• Sync_Seg = 1TQ
• 1TQ ≤ Prop_Seg ≤ 8TQ
• 1TQ ≤ Phase_Seg1 ≤ 8TQ
• 2TQ ≤ Phase_Seg2 ≤ 8TQ
• 1TQ ≤ SJW ≤ MIN(Phase_Seg1 , 4 )
• SJW–Synchronization jump width, defined as the time length by which Phase_Seg1 may be lengthened and Phase_Seg2 may be shortened
The above relationships generate a large range of possible values for each of the parameters they involve, and selecting the right combination is crucial to the successful implementation of a robust CAN communication. Designers must not only account for oscillator accuracy and propagation delays within the node in question, but also account for other system nodes with which communication must be established.
Based on the system clock, the baud rate required, and possibly the required sample point of the bit (in other words, the CANOpen sample point required at 87.5%), configuring the bit timing for CAN becomes a challenge many designers are reluctant to undertake. This perceived complexity is causing many new embedded systems to reuse legacy MCUs and even software stacks rather than adopting new products that might address the overall system requirements a better way. Unfortunately, it puts CAN in the “It's working; I don't want to touch it” category of embedded peripherals.
Figure 5 shows a sample bit-timing configuration for CAN, where creating new timing analysis or modifying a baud rate of an existing node configuration is no longer a risky task for an already operational CAN bus. By providing all specified and verified combinations of parameters to achieve a robust CAN timing implementation, designers can focus on the more complex tasks of the module's main functionality.
Although available for decades now, CAN is still perceived as a complex peripheral in an embedded systems design, especially in research and development area (R&D). R&D activities involve multiple iterations of the system configuration, with CAN being a component in the overall system. CAN drivers and CAN stack development can be outsourced to specialized companies providing these services for a fee, some with limited post-delivery change and configurability. Lately, semiconductor companies are providing tools to bridge that gap and allow quick in-house development that promises to speed time to market for complex embedded systems.
Hassane El-Khoury is the senior automotive business development manager at Cypress Semiconductor, where he heads the automotive business development and applications effort. He has over eight years of automotive electronics design experience, seven as a lead design engineer at Continental Automotive Systems doing electronic brake systems design (ESC, ABS, TCS, Regenerative Braking). Hassane has a BSEE from Lawrence Technological University in Southfiled, MI, and an MS Engineering Management from Oakland University, Rochester Hills, MI.