EiED Online>> CAN 101: CAN Can Where Ethernet Does Not

Dec. 10, 2004
CAN has existed for almost 20 years. Not quite as old as Ethernet, CAN is still a better choice for device networks, such as those found in automotive and process control applications. It also makes sense for other MCU-based networks.

Controller Area Network (CAN) was first developed by Robert Bosch GmbH, Germany, in 1986. Used then as the network for three electronic control units (ECUs) in vehicles by Mercedes, CAN has since flourished. But a significant portion of CAN microcontrollers (MCUs) continue to be used in automotive applications. It has moved into other areas, such as process control.

CAN is gaining importance in embedded applications due to a number of significant but subtle changes. First, the success of CAN in automotive and industrial controllers has increased the number of products and driven down the price. Second, connectivity has become more important as MCU-based Ethernet solutions have arrived. Developers are now more aware of the benefits of connectivity, and applications are demanding a higher level of interaction and control with remote devices.

Ethernet and CAN are actually very complementary. Although Ethernet's price and hardware cost have fallen greatly, it does not fit into the realm of CAN, as noted in the following table.

CAN Ethernet
Speed ≥1 Mbit/s 10 Mbits/s to 10 Gbits/s
Distance 100 meters 150-meter Cat 5
Packet size (min) 0 bytes 64 bytes
Packet size (max) 8 bytes 1518 bytes
Protocol standards yes yes
Max devices 2032 for 11-bit address 6-byte address
Arbitration Lossless bit wise CSMA/CD

On the other hand, CAN can address aspects of an application that Ethernet cannot economically address. Not only is Ethernet more expensive, it also requires a hub or switch that adds to the cost. CAN remains an ideal solution where low speed and small amounts of data are common. The emergence of MCUs with both CAN and Ethernet make gateway development a simple matter, allowing low-speed networks to be tied into higher speed local-area networks (LANs) and wide-area networks (WANs).

There are a number of similarities between CAN and Ethernet. Both employ bus drivers and controllers to handle the physical and data link layers. CAN typically employs a terminated, two-wire, multidrop bus (Fig. 1), whereas Ethernet now is usually a point-to-point, CAT-5 cable connection to a hub or switch.

Communication for CAN and Ethernet is packet-based. The packets contain source (Ethernet only) and destination addresses. Network controllers normally have their own memory buffers and registers for message addresses, enabling the controller to handle packet transmission and reception transparent to the host processor. The host simply supplies the data to be sent along with the destination and retrieves data from packets that the controller receives. CAN and Ethernet have a broadcast capability, although their implementations differ significantly, as do their bus arbitration mechanisms. Here, we concentrate on the CAN implementation.

CAN uses a lossless, bitwise arbitration scheme (Fig. 2). It requires a bus with a dominant and passive state and the ability for multiple controllers to drive the bus in either state without destroying the hardware drivers. Standard CAN drivers are available for this purpose, but other implementations are possible. For example, a single-wire, open collector system would work as well and could easily be employed on a single board where a custom interface would be viable.

The CAN arbitration scheme essentially has each sending CAN controller checking the bus first to see if anything is being sent and second for arbitration. In the former, a controller will wait for the end of a packet if one is currently in transit. In the latter, it starts by sending the packet header. Unlike Ethernet, CAN controllers must watch the bus to see that each bit it sends matches the bus state. If there is a difference, then a higher-priority CAN controller is attempting to send at the same time. In this case, all lower-priority CAN controllers must stop using the bus and wait to send their packet. Assuming all CAN controller addresses are unique, only one controller will eventually wind up with control of the bus after the header is sent.

The remote transmission request (RTR) bit permits a device to signal another node to provide the requested data based on the packet's address. The header, including a 6-bit control field, is followed by the packet data and a CRC.

Broadcasting Lots Of CAN Into The Inbox CAN initially was defined with an 11-bit address. A 29-bit address was defined later, allowing a single address space to handle a large number of nodes or multiple linked CAN networks. Of course, this makes the packet longer. That and the proliferation of small CAN networks is why the 11-bit addressing is still more commonly used.

A longer address is sometimes also needed due to the way CAN handles broadcasting. Actually, this is how the receiver handles a broadcast message. In this case, a CAN controller typically has one or more receive addresses. Each address has an associated mask that is used on each destination address in an incoming packet and compared with a receive address to determine whether the controller will capture the data.

This approach actually does two things. First, it allows data to be broadcast to more than one controller where each of these controllers is set up to look for the appropriate masked address. Second, because only part of the address is used for routing, the remaining address bits can be used for data. In many cases, this transmission may still be to a single node. If the least significant bit is masked out, then a 0 could indicate that a device should be turned off, and a 1 would indicate the device should be turned on. Of course, this could still be a broadcast to multiple controllers, in which case a 0 might indicate to open all the windows and a 1 to close them. There would be no need for any packet data since it is embedded in the address.

CAN controllers typically implement multiple mailboxes. An address and a mask are associated with a mailbox so incoming messages with matching addresses can be stored there. An alternative implementation has a single mailbox but messages are added in FIFO order and retain their address and mask information.

As you may have figured out, unlike an Ethernet device, CAN nodes aren't restricted to a single address. In fact, the data in CAN packets is actually what is identified by the address, and this field is typically called the object identifier.

CAN system design typically starts with the collection of types of information to send and giving them identifiers, keeping the implied priority in mind. These may be grouped to make it easier to use masks. Next, the nodes where the data must go have to be identified. Finally, the CAN controllers must be programmed to handle the desired packets. Most controllers can automatically handle only a limited number of mailboxes, so it behooves the designer to properly allocate the CAN address space.

One side benefit to this data-tagged approach is the ability to split or merge data-processing chores without changes to the source of the information. For example, it's possible to take two CAN MCUs and merge them into a single CAN MCU to handle the same set of messages simply by setting up the single MCU's CAN module to receive both sets of messages.

So far, we have looked at only the CAN basics. It's possible to employ higher-level protocols using CAN.

CAN Protocols There is not enough time to present CAN protocols like CANOpen and DeviceNet here, but we will get to it in latter articles. The higher-level CAN protocols specify how the address space and data in a packet are used. This enables such features as determining a device's feature set. These protocols are very useful when working with CAN products from many vendors. For example, an industrial control system might use third-party actuators and sensors that employ the same higher-level CAN protocol.

Another place where CAN has expanded its realm is in time-critical applications. In this case, CAN uses a Time Triggered Protocol (TTP), where packets are fit into slots that guarantee a fixed-time delivery. This is important in many safety-critical areas including drive-by-wire and brake-by-wire. The Flexray Consortium is one standards organization involved in this enhanced CAN arena.

CAN Kits Sorry, I haven't had the time yet to get to all the CAN kits I have received. But their coverage will be next in this series, with a close look at CAN protocols coming after that. I will be taking a look at Microchip's PICDEM CAN-LIN 2 demo board (Fig. 3). It contains a pair of PIC18 MCU chips and a LIN slave controller.

Local Interconnect Network (LIN) is CAN's little brother. It's even simpler to implement, slower, and designed for controlling very simple devices. It is akin to I2C and other low-speed device buses. I'll also address LIN in more detail as well. I2C isn't the only networking alternative for low-end networks.

What MCU-based networking technology are you using? Drop me an e-mail and let me know at [email protected].

Related LinksCAN in Automation (CiA)
www.can-cia.de

Microchip
www.microchip.com

Flexray Consortium
www.flexray.com

About the Author

William G. Wong | Senior Content Director - Electronic Design and Microwaves & RF

I am Editor of Electronic Design focusing on embedded, software, and systems. As Senior Content Director, I also manage Microwaves & RF and I work with a great team of editors to provide engineers, programmers, developers and technical managers with interesting and useful articles and videos on a regular basis. Check out our free newsletters to see the latest content.

You can send press releases for new products for possible coverage on the website. I am also interested in receiving contributed articles for publishing on our website. Use our template and send to me along with a signed release form. 

Check out my blog, AltEmbedded on Electronic Design, as well as his latest articles on this site that are listed below. 

You can visit my social media via these links:

I earned a Bachelor of Electrical Engineering at the Georgia Institute of Technology and a Masters in Computer Science from Rutgers University. I still do a bit of programming using everything from C and C++ to Rust and Ada/SPARK. I do a bit of PHP programming for Drupal websites. I have posted a few Drupal modules.  

I still get a hand on software and electronic hardware. Some of this can be found on our Kit Close-Up video series. You can also see me on many of our TechXchange Talk videos. I am interested in a range of projects from robotics to artificial intelligence. 

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!