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].
www.can-cia.de
Microchip
www.microchip.com
Flexray Consortium
www.flexray.com
