Controller Area Network

10 May

Controller Area Network: The TINI microcontroller and the TINI API support dual Controller Area Network (CAN) interfaces. CAN is a popular network for communicating between sensors and controllers in automotive and industrial applications. In this chapter we will discuss some of the details in the CAN specification and get you started using TINI as both a CAN controller and a CAN sensor interface.

What Is the CAN Bus?
General overview

The Controller Area Network (CAN) is a serial bus system that was developed in the late 1980s for automotive applications by Robert Bosch GmbH, Germany. CAN was developed to support distributed control systems in automobiles and has also been implemented fairly widely in industrial control systems as well.

Figure 12-1: A CAN bus
CAN uses bit-serial transmission at rates up to 1 megabit/second in twisted-pair cabling. Messages are passed between nodes on a CAN bus using a message identifier. CAN is similar to I2C, which was discussed in the previous chapter, with a few significant differences. The primary differences are the signaling and the method of identifying devices and data. CAN uses differential signaling on two wires rather than the clock and data lines that I2C uses. With CAN the data has the identification, where in I2C the devices have the identification. This identifier does not indicate the transmitting or receiving device but rather identifies the content of the message (for instance, temperature or shaft position). All nodes on a CAN bus receive all of the messages and check the message identifier to determine if that particular message is of interest. The identifier also determines the message priority. Lower numerical values have a higher priority on the CAN bus. The CAN specification is available from the Bosch CAN Literature1 web page. Additionally, CAN has been standardized by the International Standards Organization in ISO 11989 (Controller area network for high-speed communication) and ISO 11519 (Low-speed controller area network). The Bosch CAN specification only defines the Data Link and Physical Layers (using the OSI reference model). Additional layers are defined in one of several higher-level protocols that use CAN for the Data Link layer. A few of these higher-layer protocols will be mentioned soon. The details of CAN are essentially transmission media independent, but the ISO specifications have defined the Physical layer, including cabling and connectors.

CAN versions
The Bosch CAN specification has been revised over the years from version 1.0 to the current version of 2.0. Version 1.0 and 1.2 defined CAN with an 11-bit message identification. Version 2.0 has allowed an 18-bit message ID extension allowing for an effective 29-bit message ID. To keep new CAN devices compatible with older implementations, the CAN 2.0 specification is defined in two parts, 2.0A and 2.0B. In CAN 2.0A, the message format is consistent with older versions of CAN that use only an 11-bit message ID. In CAN 2.0B the 18-bit message ID extension is allowed. CAN 2.0B can then be implemented in either the passive or active mode. In the passive mode, the CAN controller will transmit only messages with 11-bit message IDs and will receive message frames with the standard 11-bit and the extended 29-bit ID. In this way it can be compatible with both older and newer CAN devices. In the active mode the CAN controller receives and transmits messages with both 11-bit and 29-bit message IDs. CAN version 1.0, 1.2 and 2.0A are called “standard CAN” because they all use an 11-bit message ID. CAN 2.0 B is called “Extended CAN” as it uses the extended 29-bit message ID.

Random Posts

Comments are closed.