Serial Communication in Harsh Environments: A New CAN Transceiver from Maxim

CAN-bus transceivers such as the MAX14883E provide robust, convenient communication for demanding applications.

We are constantly hearing about I2C these days; SPI and UART are also well-known abbreviations. In contrast, I would not be surprised to find that many engineers and electronics enthusiasts have little knowledge of, or at least little experience with, the CAN bus.
This is not particularly surprising: the CAN (Controller Area Network) bus is not an all-purpose standard like I2C or SPI. It was developed for automotive applications, and it is also used in industrial environments. If you don’t do professional design work for automotive or industrial systems, you may hear very little about CAN.
This article is by no means a comprehensive discussion of the CAN bus, but here are a few salient characteristics:

• It’s a multi-master bus; in other words, it does not use a master/slave arrangement. The devices on the bus are simply referred to as “nodes,” which I appreciate, because the “master/slave” thing starts to grate on my ears after a while. Seriously, who ever thought that it was a good idea to borrow terminology from one of humanity’s most notorious and despised institutions?
• It’s not intended for point-to-point communication; messages are broadcast to the entire bus.
• Differential signaling is used, which as usual provides enhanced immunity to noise. And it’s a two-wire bus, so the primary interconnection is just one twisted pair, as follows:

Diagram taken from the MAX14883E datasheet.

 

• The maximum data rate is 1 Mbps. This may seem painfully slow compared to 500 terabytes per second or whatever USB 3.0 is doing these days, but typical CAN bus applications simply do not need that kind of bandwidth. We have to remember that high frequencies complicate just about everything—good design practice means limiting the data rate according to the actual communication needs of the system.
• CAN data is transferred in packets. “Packetization” is an important technique for making communication systems more robust; you can read about it here.
• In case you want to get information directly from the source, the official documents governing the CAN protocol begin with ISO-11898. I don’t know much more than that because my brain turns off as soon as I see the letters “ISO.”

Block Diagram

The MAX14883E is an integrated CAN transceiver. The integration aspect is important because connecting to a CAN bus isn’t quite as simple as, for example, driving digital signals onto an SPI or UART line. You can see the various portions of the device in the following diagram:

Diagram taken from the datasheet.

Protection

Note the “protection” blocks; CAN is intended for harsh environments, and CAN transceivers need to be able to cope with rough conditions. The MAX14883E protects against faults up to ±60 V, and the two CAN lines can survive ESD up to ±10 kV (or ±15 kV, or ±22 kV—it depends on which flavor of ESD you’re interested in).
Then there is the issue of common-mode voltage. It is perfectly possible for different nodes to have different ground potentials. The universal solution to this problem is galvanic isolation, but that approach is inconvenient and generally used only when necessary. The preferred method is to use differential signaling and then make the interface circuitry tolerant of unpredictable ground potentials. The CAN standard requires transceivers to support a common-mode range of –2 V to +7 V, but the MAX14883E goes far beyond that: its “functional common-mode input range” is ±25 V.

Dominance

Another safety feature is the “dominant timeout.” The CAN protocol uses the terms “dominant” and “recessive” to describe the actual signal levels. You can see the dominant and recessive logic states in the diagram below. As the name implies, a dominant signal level means that the bus is not available for new messages. This is fine, unless a transmitter experiences a fault and locks the bus into a nonfunctional dominant state. The dominant-timeout functionality prevents this type of failure by automatically returning the signals to the recessive state if the CAN lines are in the dominant state for longer than t_DOM (somewhere between 1.3 and 4.3 ms).

Adapted from a diagram in the datasheet.

This diagram is a good reminder that CAN doesn’t follow the expected relationship between logic level and the state of the actual CAN signals: a logic-low input places the output in the dominant state, and a logic-high releases the bus into the recessive state.

---

Have you seen the CAN bus used outside of automotive and industrial environments, e.g., for consumer or military applications? Let us know in the comments.