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 I2C (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.
View the full-size image
