Design Article
CAN in 30 minutes or less
Hassane El-Khoury
11/1/2009 12:00 AM EDT
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.
Comments
raj miriyala
11/2/2009 7:57 AM EST
The article was good... but a small erratum SPI - mentioned as "System Packet Interface" is a network protocol. I guess the author intends to print "Serial Peripheral Interface"
Sign in to Reply
danish
11/13/2009 7:33 AM EST
Appreciate if information on CAN Hardware is also available. Our Designs have Microcontrollers how easy it is to have CAN node implemented with major hardware modifications.
Sign in to Reply
djbuijs
11/16/2009 4:36 PM EST
While it is nice to see an article on CAN, I'm not sure whether it really lives up to its title. Some CAN history, bit-timing and tool screenshots, but not a single example of where such tools are found or how to setup CAN from scratch with them....
Nonetheless, the author is absolutely right when it comes to setting up CAN for the first time: while the protocol is robust, flexible and with the Full/Enhanced controllers takes hardly any effort for your MCU, the initial design can be very tricky. There are some free implementations available (Pelican, VSCP, CAN-Open, DeviceNet), but when you want to do something simple (where these protocols simply don't fit), where a bus network like CAN seems appropriate instead of Peer to peer RS232 or maybe bus RS 485/422, the very advantage CAN has in the form of message based communications, becomes a burden while designing your app around it. Especially, as the author also points out, when it comes to combining the various incarnations of CAN (Basic, Full, enhanced).
Sign in to Reply
Umut Tezduyar
11/17/2009 7:11 PM EST
Thank you very much for this nice article Hassane. I would like to bring up a little point that J1939 implementers will appreciate. According to SAE spec, J1939 has to run at 250kbit/sec. This makes J1939 bit timing to 4 micro second. Since 1 bit is 8 to 25 time quanta, make sure your oscillator can run at a perfect frequency so that your CAN device can meet the SAE spec.
Sign in to Reply