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.

Other sources of information:

http://www.can-cia.org
http://en.wikipedia.org/wiki/Controller_Area_Network
http://en.wikipedia.org/wiki/RS-485
 

Distributed control systems at home

Distributed control is a concept originated along the 70's to cover the needs of a growing industry in terms of automation. Before that, centralized automation systems, where a main computer did all the measurements and controls, were the only valid model at those times. The need of distributing the intelligence along an industrial plant and avoiding complex cable layouts made some companies think about a way of providing a communication method for their controllers. That was the genesis of the field buses. The overall solution was then progressively adopted by the industry so that nobody questions nowadays the advantages of the distributed control model.

Distributed control systems are typically found in the manufacturing industry and also in buildings, vehicles, planes and vessels. Nevertheless, is the distributed model really suitable for home automation applications? At the beginning of our current century Microsoft tried to impose a centralized model based on a PC running Windows. Microsoft knew that no distributed control system could compete against a PC in terms of flexibility, power and price. Moreover, most of the home automation manufacturers already provided drivers and applications for controlling their systems from a Windows machine. Other companies as HomeSeer Technologies or Home Automated Living have been providing very good tools for transforming a simple PC into a programmable home controller with lots of functionalities at very competitive prices. Under this panorama, the professional distributed systems found an important adversary in the home environment. Only Lonworks and EIB seemed to gain some part of the market to the PC-based system. Other distributed systems as CBUS or InstallBus also got some success but only in some localized markets. These distributed systems are commonly installed in large houses so that they provide important savings in cable runs. But the small and medium houses are still dominated by the centralized systems. Home automation devices rarely are as powerful as any industrial controller. Moreover, they usually emphasize on the low complexity of installation rather than on other aspects, most of them vital in other environment (speed of communication, robustness, programming capabilities, etc). Moreover, most pure home controllers (not building controllers) often delegate in the external PC the responsibility of taking the most complex decisions. As result, implementing a PC-based home automation network in a medium-size house or apartment is often less expensive than using distributed systems. As result, distributed systems are usually economically advantageous in large installations, where the costs of installing complex cable runs are not justified.

Ok, so could we state that PC-based central systems are less expensive than distributed systems for the home? But what about other aspects? Is then the PC-based model the best for home automation applications? This is also a very personal point of view, but I think that distributed systems are less error-prone, as every controller does a different job, in contrast to the PC-based system, where a computer maintains a number of tasks and the complexity of the system is sometimes exponentially proportional to the amount of endpoints to control. Hence the popular phrase: "when the computer gets halted, the whole installation gets useless".

Thus, must we live with that dilemma? low cost against robustness? As a home automation enthusiast and developer of embedded controllers I began thinking about a way of breaking that rule. First I thought that Linux and low cost 32-bit platforms could be a good starting point. Then I discovered some good open-source resources that perfectly complemented the idea that I had in mind. After more than two years of work the opnode project is taking shape...