What is CAN bus?

The Controller Area Network (CAN bus) enables communication.

Controller Area Network (CAN) is a serial network technology designed for the automotive industry, especially for European cars but has also become a popular bus in industrial automation and other applications.

The CAN bus is primarily used in embedded systems and an network technology that provides fast communication among microcontrollers up to real-time requirements, eliminating the need for the much more expensive and complex technology of a Dual-Ported RAM.

CAN is a two-wire, half duplex, high-speed network system far superior to conventional serial technologies such as RS232 in regards to functionality and reliability, yet CAN implementations are more cost-effective.

While, for instance, TCP/IP is for the transport of large data amounts, CAN is designed for real-time requirements and with a 1 MBit/sec baud rate can easily beat a 100 MBit/sec TCP/IP connection when it comes to short reaction times, timely error detection, quick error recovery and error repair.

You configure BaudRate as bits per second. The transferred bits include the start bit, the data bits, the parity bit (if used) and the stop bits. However, only the data bits are stored.

The baud rate is the rate at which information is transferred in a communication channel. In the serial port context, “9600 baud” means that the serial port is capable of transferring a maximum of 9600 bits per second.

If the information unit is one baud (one bit), then the bit rate and the baud rate are identical.

If one baud is given as 10 bits, (for example, eight data bits plus two framing bits), the bit rate is still 9600 but the baud rate is 9600/10, or 960.

You always configure BaudRate as bits per second. Therefore, in the above example, set BaudRate to 9600.

Please note, both the computer and the peripheral device must be configured to the same baud rate before you can successfully read or write data.

Standard baud rates include 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000 bits per second.

CAN networks can be used as an embedded communication system for microcontrollers and as an open communication system for intelligent devices. Some users, for example, in the field of medical engineering, opted for CAN because they have to meet particularly stringent safety requirements.

Similar requirements had to be considered by manufacturers of other equipment with very high safety or reliability requirements (e.g. robots, lifts and transportation systems).

The greatest advantage of Controller Area Network lies in the reduced amount of wiring combined with an ingenious prevention of message collision (meaning no data will be lost during message transmission).

The following shows a need-to-know overview of CAN’s technical characteristics:

Many microprocessor chips, such as the ARM Cortex-M3 processor, provide interfaces including Ethernet, digital I/O, analogue I/O, USB, UARTS, and Controller Area Network. However, that does not mean that you can use the chip “as is” and connect it to a network, sensors, etc.

All of these interfaces require a “hardware driver.”

In the case of serial technologies such as RS232 or CAN, you will need the corresponding transceiver.

In the specific case of the CAN bus controller, we need a line driver (transceiver) to convert the controller’s TTL signal to the actual CAN level, which is a differential voltage. The use of differential voltage contributes to the vast reliability of CAN.

Even though it is effective in automobiles and small, embedded applications, CAN alone is not suitable for projects that require a minimum of network management and messages with more than eight data bytes.

As a consequence, higher-layer protocols (additional software on top of the CAN physical layer) such as CANopen for industrial automation and SAE J1939 for off-road vehicles, were designed to provide an improved networking technology that support messages of unlimited length and allow network management, which includes the use of node IDs (CAN supports only message IDs where one node can manage multiple message IDs).

Ironically, however, it is very well foreseeable that the basic CAN technology will prevail over higher-layer protocols for the automation industry such as CANopen and DeviceNet, due to its continued use in automobiles.

These days, CANopen and DeviceNet are “dead” protocols when it comes to new developments. The only exception is SAE J1939, which is closely connected to the diesel engine technology and that includes, yet again, vehicles.

Some find CANopen to be a fairly complex and tremendously over-bloated protocol with a disappointingly low bandwidth. Add to this that CANopen is rapidly losing its attraction for the automation industry due to the emergence of the more powerful Industrial Ethernet protocols and now there are two reasons why I never attempted writing a CANopen stack.

The Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee has developed a family of standards concerning the design and use of devices that transmit electronic signals and control information among vehicle components.

SAE J1939 and its companion documents have quickly become the accepted industry standard and the Controller Area Network (CAN) of choice for off-highway machines in applications such as construction, material handling, and forestry machines.

Derivatives of SAE J1939 include:

The DeviceNet Specification, consisting of two volumes: Volume One – Common Industrial Protocol (CIP) and Volume Three- DeviceNet Adaptation of CIP, is available only for ODVA (Open DeviceNet Vendor Association) members.