A Brief Introduction To Controller Area Network

Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

07/06/2019 A Brief Introduction to Controller Area Network

Call us on 413-475-3651 My Account Gift Certificates Wish Lists Sign in or Create an account

Search

Arduino Breakout Boards OBD-II & J1939 Cables CAN FD CAN Bus CAN Bus Logger

Embedded Systems Gateways Internet of Things LIN Bus Literature LPC1768 Kits

Raspberry Pi SAE J1939 Sensors Teensy Wireless OEM Products Specials/Sellouts

Shipment

Home Documentation A Brief Introduction to Controller Area Network

A Brief Introduction to Controller Area


Network
Controller Area Network (CAN) is a serial network technology that was originally designed for the
automotive industry, especially for European cars, but has also become a popular bus in industrial
automation as well as other applications. The CAN bus is primarily used in embedded systems, and as
its name implies, is a 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.

Introduction

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

https://copperhilltech.com/a-brief-introduction-to-controller-area-network/ 1/6
07/06/2019 A Brief Introduction to Controller Area Network

While, for instance, TCP/IP is designed for the transport of large data amounts, CAN is designed for
real-time requirements and with its 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.

CAN networks can be used as an embedded communication system for microcontrollers as well 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).

Without CAN - With CAN

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

Controller Area Network

Is a serial networking technology for embedded solutions.


Needs only two wires named CAN_H and CAN_L.
Operates at data rates of up to 1 Megabit per second.
Supports a maximum of 8 bytes per message frame.
Does not support node IDs, only message IDs. One application can support multiple message IDs.
Supports message priority, i.e. the lower the message ID the higher its priority.
Supports two message ID lengths, 11-bit (standard) and 29-bit (extended).
Does not experience message collisions (as they can occur under other serial technologies).
Is not demanding in terms of cable requirements. Twisted-pair wiring is sufficient.

CAN Interface Hardware

A great variety of microprocessor chips, such as the ARM Cortex-M3 processor, provide interfaces such
as Ethernet, digital I/O, analog I/O, USB, UARTS, and, last but not least, Controller Area Network.

https://copperhilltech.com/a-brief-introduction-to-controller-area-network/ 2/6
07/06/2019 A Brief Introduction to 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 some kind of a “hardware driver.” In 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.

The next image compares both signals, TTL and differential voltage:

The actual signal status, recessive or dominant, is based on the differential voltage between CAN_H
and CAN_L (2V during dominant bit time; 0V during recessive bit time).

CAN-Based Higher-Layer Protocols

https://copperhilltech.com/a-brief-introduction-to-controller-area-network/ 3/6
07/06/2019 A Brief Introduction to Controller Area Network

Even though extremely 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, specifically 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.

CANopen

Is suited for embedded, industrial applications


Was originally designed for motion control
Was developed and is maintained by the CAN-in-Automation User Group

Like CAN, the CANopen standard is the responsibility of CiA (CAN-in-Automation). For further
information, refer to their website at http://www.can-cia.org.

Note: I personally consider 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.

SAE J1939

Defines communication for vehicle networks (trucks, buses, agricultural equipment, etc.)
Is a standard developed by the Society of Automotive Engineers (SAE)

The SAE J1939 Standards Collection can be found exclusively on the Web at http://www.sae.org.

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:

https://copperhilltech.com/a-brief-introduction-to-controller-area-network/ 4/6
07/06/2019 A Brief Introduction to Controller Area Network

NMEA 2000 for marine applications


ISOBUS (ISO 11783) for agricultural applications
MilCAN for military applications

Note: In my book SAE J1939 ECU Programming & Vehicle Bus Simulation with the Arduino I introduce
ARD1939, an SAE J1939 protocol stack for Arduino Uno and Mega 2560. The stack and the associated
sample programs will also work on the Arduino Due.

DeviceNet

Is suited for industrial applications (floor automation)


Was developed by Allen Bradley/Rockwell
Is maintained by Open DeviceNet Vendor Association (ODVA)

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.

For further information, refer to http://www.odva.org.

A Comprehensible Guide to Controller Area Network


by Wilfried Voss represents the most thoroughly
researched and most complete work on CAN available
in the marketplace.

Controller Area Network (CAN)
is a serial network technology that was originally
designed for the automotive industry, especially for
European cars, but has also become a popular bus in
industrial automation as well as other applications. The
CAN bus is primarily used in embedded systems, and as
its name implies, is a 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.

This book provides complete
information on all CAN features and aspects combined
with a high level of readability. => Read more...

SIGN UP FOR OUR Name Email SUBMIT

NEWSLETTER

https://copperhilltech.com/a-brief-introduction-to-controller-area-network/ 5/6
07/06/2019 A Brief Introduction to Controller Area Network

Quick Links Categories Brands

About Us Arduino Copperhill Technologies

Contact Us Breakout Boards SK Pang Electronics

Shipping & Returns OBD-II & J1939 Cables WaveShare

Privacy Policy CAN FD Seeed Studio

Forum CAN Bus Yason

Blog CAN Bus Logger CSS Electronics

Documentation Embedded Systems HAOYU Electronics

CAN / SAE J1939 OEM Gateways Pi Supply


Services
Internet of Things ElecFreaks
Electronic Logging Device
(ELD) Rule LIN Bus Embedded Artists

RSS Syndication Literature View all brands

LPC1768 Kits

Raspberry Pi

SAE J1939
Sensors

Teensy

Wireless

OEM Products

Specials/Sellouts

Shipment

All prices are in USD. © 2019 Copperhill. Sitemap Powered by

https://copperhilltech.com/a-brief-introduction-to-controller-area-network/ 6/6

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy