eCos Reference Manual
Prev |  | Next

# Chapter 30. Overview

# Description

The Controller Area Network, CAN, is a multicast shared, differential serial bus standard especially suited for networking "intelligent" devices as well as sensors and actuators within a system or sub-system. The protocol was originally developed in the 1980s by Robert Bosch GmbH aiming at automotive applications. Nowadays CAN has gained widespread use and is used in industrial automation as well as in automotive, mobile machines and in many embedded control applications.

The CAN protocol is defined by the ISO 11898-1 standard. The physical layer uses differential transmission on a twisted pair wire. CAN uses a non-destructive bit-wise arbitration to control access to the bus.

There is no explicit address in the messages because in CAN networks there is no addressing of subscribers or stations, but instead, each message carries a prioritized identifier. A transmitter sends a message to all CAN nodes (broadcasting). The identifier may serve as an identification of the contents of the message and also determines the priority that the message enjoys in competition for bus access. A node decides on the basis of this identifier received whether it should process the message or not.

The CAN messages are small (at most eight data bytes) and are protected by a checksum. Each CAN message consists of an 11 bit message ID, up to 8 bytes of data and, a CRC checksum and a number of control bits. These short messages ensure a robust transfer of data in electromagnetically noisy environments. An extended version of the CAN frame supports 29 bit message identifiers.

Basically there are two different operational modes for CAN receivers - FullCAN and BasicCAN. The difference between these two modes is the Object Storage function. The BasicCAN architecture is quite similar to a simple UART. A BasicCAN device has typically one transmit buffer and two receive buffers. The CAN chip handles only the transmitting and receiving of the data (and the error handling) and so most of the manipulation of the data has to be done by the CPU. The CPU has to request the transmitting or acknowledge the receiving of the data through the interrupt flags. This will burden the CPU and take up much of the CPU time.

The FullCAN architecture is more suitable for high-speed performance. It has its own storage area on chip and works with a number of message buffers or message boxes. The CAN controller has its own Acceptance Filtering Mask on chip. It can thus determine which frames are to be received by examining the identifiers. The CPU in this case will only receive the valid (wanted) frames and hence improve the performance of the CPU.

You can find more information at the CAN in Automation website.

Prev | Home | Next
CAN Support | Up | eCos Support for CAN