External links

RS485 vs CAN

This question usually arises during the initial evaluation of
communication technologies in any project with distributed control
requirements. This article pretends to describe the differences between
these two technologies and finally offer a way of deciding which of
them is the best for our application, bearing in mind the key
requirements of our project: lead time, budget, platform and
development skills.

RS485 was created in 1983 as a way of
providing multidrop communication capabilities for devices with at
least one UART. RS485 is often called the "multiplexed" RS232 - any of
the devices connected to the bus can talk to any other in half-duplex
mode. Half-duplex means that the communication is bidirectional but
only one device can transmit at a time (one transmits, the other listen
to it, and so on). But RS485 is not a protocol, it's just the physical
path and the basic rules over which any device can communicate. RS485
provides a way of transmitting serial messages over the multidrop bus
but the contents of these messages are totally user-defined. The
structure of the communication frame, the time that a message must be
transmitted at, the way of addressing devices on the bus, the method
for avoiding data collisions, etc are some of the steps that a designer
must cover when defining a protocol over RS485.

CAN (Controller
Area Network) was created in the 80's by Robert Bosch GmbH and it
initially targeted the automotive industry. CAN, in contrast to RS485
not only provides a physical media for communicating but also defines
the necessary mechanics for addressing packets and avoiding data
collisions. CAN specifies the structure of the data frame - the
position and number of bytes for the address the data and the control
bytes. Everything follows a precise structure and a timing in order to
guarantee quality of transmission, delivery of every transmitted
packet, speed and also avoid corruption of data. CAN is thus a very
secure technology, and because of that it's currently been used in
critical environments as vehicles, planes, vessels and the industry in
general.

Implementing CAN from scratch is not necessary as there
is nowadays an important amount of manufacturers selling CAN
controllers and microcontrollers with the whole CAN stack included. As
result, CAN is often preferred because it provides a simple way of
designing true multimaster systems without having to define a protocol
from scratch. On the other hand, RS485 is typically used in
master-slave environments, where a data collision detector is not
necessary. The cost in components is also lower in the RS485 case as
most microcontrollers have an UART port, even the smallest ones. On the
other hand, CAN usually needs more expensive microcontrollers with
larger memory and an integrated CAN controller or a SPI port for
driving an external CAN controller. This makes CAN a bit overkilled for
small distributed sensors even if it can't be considered an expensive
solution.

The following table tries to summarize the most common features of both technologies:

Feature

RS485

CAN

Necessary microcontroller interface

UART

CAN controller or SPI

Native system for detecting data collision

No, it must be implemented in software if necessary

Yes, CSMA/CD

Maximum communication speed

10 Mbit/s

1 Mbit/s

Maximum bus length

1200 m (at 100 kbit/s)

500 m (at 125 kbit/s)

Layers in the ISO model

Physical layer

Physical layer and data link layer

Maximum amount of data into a single frame

Unlimited, it depends on your application

8 bytes

Component costs

Very low

Low-medium

Development time

medium/high

low/medium

Typical use

Master-slave applications

Multimaster applications

Examples of popular protocols

Modbus RS485, Profibus

CanOpen, Devicenet, J1939

Does
this mean that RS485 is only suitable for master-slave protocols? Not
necessarily. A number of vendors have implemented their own proprietary
multimaster protocols based on RS485. The way they detect collisions
and ensure data integrity is not known but the solution itself is
indeed possible. Some open multimaster protocols use control bytes for
reserving/releasing the bus and even detecting collisions when at least
two address fields get overlapped. Another possible solution is to use
of some kind of synchrony between nodes.