CAN - Controller Area Network

CAN is used pervasively in several industries -

And this just names a few examples.

Why CAN? The more compelling reasons are the simplicity, reliability, and cost of connecting two (and usually more) devices to a single network. CAN is built-in to most modern microcontrollers, and with the addition of an inexpensive external transceiver chip at each node, they can begin to share information on a bus. Before CAN, in many of these types of applications, an additional wire for each circuit was used. Wiring harness complexity and weight was growing out of control. So, CAN was an enabler for simplifying the wiring of complex systems. In exchange, some additional complexity in the software was the trade-off.

Why not Ethernet? I'd say availability and cost are two of the key drivers here. In the domain where CAN excels, the system does not need 10, 100, or 1000 Mbit/sec communications. Additionally, while Ethernet is becoming common on microcontrollers, it still requires a much more expensive external transceiver, and it is most commonly connected to a switch, not a bus - adding yet another complex piece of equipment.

Consider for a moment how CAN is used in off-road machinery. The transmission and the instrument cluster both need Engine speed as an available parameter. The transmission may need it 100 times per second, and the display might only need it from 1/2 to 10 Hz, depending on how it is displayed. Sent at 100 Hz (every 10 msec) is easy for CAN, and the system cost to do only this is perhaps just a few dollars. One of these systems typically has the communication rate set to 250 kbits/sec, which permits sending a packet about every 560 usec. So, this Engine speed message is using about 5% of the network bandwidth (0.5 msec/packet * 100 packets / 1000 msec => 5%). And since this is often among the fastest recurring messages on the network, this leaves a lot of bandwidth for other purposes - like lighting, turn signals, communicating engine coolant and transmission oil temperature, and so on.

A CAN Packet

Here's a slightly "exploded" view of a CAN frame.

A single CAN packet is composed of a number of items, but starting at the most macro level, there are two:

• The message identifier is a header that is sent ahead of the data. This identifier is chosen to uniquely identify what type of data is carried by this message. Sending nodes prefix the identifier to the data, and receiving nodes inspect the identifier to see if the message is of interest. CAN supports two formats for this - one is an 11-bit identifier and the other a 29-bit identifier (as shown above). Depending on the protocol, or the number of unique messages you need to support, one or the other is fine. The 11-bit takes less "network time", but the 29-bit offers a lot more options...
• The data is the next item. Interesting, a single CAN packet can carry from zero up to 8 bytes of data (a). It cannot send more in a single packet - which is part of what makes CAN so effective - higher priority messages that need to be sent experience only a short delay if they didn't get to the network ahead of a lower priority message. This helps ensure that real-time deadlines can be met.

Breaking the packet down into a bit more detail, we would find:

• The Start Bit, much like exists for other asynchronous serial communicates (e.g. RS-232) is a single bit that gets the attention of all receiving nodes. It is the transition from bus idle to busy.
• The Message Identifier - as described above.
• Some Control bits come next, and a few are woven in the identifier (at the "mid-point" between the 11 and 29-bit variants). There are several mechanisms in the control bits (not detailed here), but the most significant for discussion is a field called the DLC - Data Length Control. The DLC communicates how many data bytes are in the packet. You might wonder about the 4-bit DLC and the permissible data length from 0 to 8 bytes. For this version of CAN, DLC values from 9 to 15 all translate (in the CAN bit processor) to 8 bytes.
• Data - as described above - from 0 to 8 bytes as defined by the DLC.
• CRC is a cyclic redundancy check, and is automatically managed by the CAN bit processing engine. The hardware computes the CRC in the transmitting node and sends it with the message. In the receiving nodes, the hardware again computes the CRC and compares it with what was received to ensure the message was undamaged during transmission. The probability of a corrupted message being delivered and processed by a receiver is phenomenally low.
• Acknowledge is a spot in the bit-stream where other nodes on the network can acknowledge that they received the message. This tells the transmitter that at least one other node successfully received the message. It does not tell the transmitter that _all_ other nodes received the message. Without at least one additional node on the network, the originating node will constantly retransmit the same packet - awaiting an acknowledge.
• EOM - End of message. This is where the bus returns to the idle state for a minimum number of bit intervals before another message may be sent.

• Stuff Bits - In CAN, since the bit stream is an asynchronous stream of bits, it is important that the transmitter and receiver stay in-sync. If the message to be sent consisted of a long stream of 1s or 0s, and the transmitter and receiver clocks were not in lock-step, drift could cause the receiver to see a different stream of bits. In order to provide opportunities to resync, there is a mechanism to automatically inject an inverted bit (a "stuff bit"). This inverted bit provided "edges" from which the receiver can re-synchronize its clock to that of the transmitter.

(a) There is a newer technology of CAN called CAN-FD which can send up to 64 bytes in a single packet. As the LPC1768 does not support this, it is not discussed here.

Stuff Bits

In an effort to show the stuff bits in action, the following [rather exaggerated] example may help. At the top is what the transmitting node sent (a 'S'tart bit followed by 0xFFFF0).

The second line is what a receiver (which is running at a slightly slower clock-rate) might receive. Note the misinterpretation toward the end, where the receiver extracts E0 instead of F0.

To avoid this, the transmitter will never send 6 of the same bit values in a row; the transmitter automatically injects a reversed bit (the stuff bit), as you see in the 3rd trace. The receiver understands the same logic, so when it sees the transition induced by the stuff bit, it realigns its receive clock to that edge, allowing it to recover the data stream accurately.

There are several other mechanisms built into the CAN bit processing engine, to detect other variants of malformed messages and report them. All of these together help ensure reliable and unaltered delivery of a message from one node to others.

One of the other key behaviors of CAN is a mechanism called non-destructive arbitration. If two messages are sent to the network at the same time (from two or more nodes), CAN will automatically determine which message is the more important (higher priority) and deliver it successfully to the network while the lesser priority messages politely delay until the bus goes idle, then they try again - all built into the CAN microcode. Which message is higher priority? The one with the lower numeric value for the identifier. This brings the point that no two messages should ever deliver a message with the exact same identifier.

mbed CAN

The LPC1768 mbed has two CAN channels available. To get started, it is common to wire them together, so one channel can send messages to the other (and vice-versa). This is the basis for the examples for CAN. By adding another mbed, you simply connect it to the same party-line (bus), and it too can participate in the communications.

A simple circuit looks like this: There are many brands of CAN transceivers; Microchip. TI, Infineon, NXP, and ST just to name a few. The chip package is also available in various surface mount and DIP packages. The more common parts are all 8-pin and usually pinout compatible. Most are operated from 5v, and some are 3/3.3v parts. The design of CAN is such that you can mix and match transceivers from any company and it should work fine. When you are just getting started, a general recommendation is to not do that - to reduce by one the number of things that might not work quite right.

CAN Bus

After moving from a simple circuit on a bench toward a "real" CAN Bus, the advantage becomes apparent. As a single twisted pair to which every node is connected, it greatly simplifies the wiring. The long cable is often referred to as the CAN "Backbone", and each node is connected as a "Stub" from the backbone. Common practices are to keep the length of each "stub" relatively short and to place a 120 ohm termination resistor at each end.

While CAN and Ethernet have not traditionally competed with each other (b), it does make a good comparison in the wiring technology. With Ethernet, it is common to have a network switch, to which each node is individually connected. This can increase the overall harnessing significantly. And 100 Mb/s Ethernet uses 4-wires (2 twisted pair). Note also that the Ethernet solution requires an additional device on the network (the "Switch"), which further increases the overall cost of the system. Even at each end-point, the cost associated with an Ethernet node could easily range from one to several dollars, compared to the fraction of a dollar for CAN.

(b) This competition is really heating up in the automotive market. CAN is very "light weight" in both software and hardware, and serves well to send signals across the network (speed, temperature, turn-signal status, and so on). Ethernet has made inroads in multimedia - camera systems primarily. But as the need for performance increases, and as the differential cost to implement Ethernet erodes, there is work in the standards committees to leverage the speed and standardization of Ethernet for more control applications.

CAN Message Structure

As a quick recap to what was written above, CAN messages placed on the network have an Identifier, and Data. For CAN on the mbed, you can send from zero to eight bytes of data in a single packet. There is additional information automatically included to make the communications more robust - a start bit, some control (DLC - data length count to identify how many bytes are being sent), a CRC (cyclic redundancy check, to ensure that the message as received is what was sent), and some acknowledge bits (that the message was received by at least one node). Even beyond this, there is some additional information - stuff-bits, which are automatically inserted whenever there are 5 or more of the same bits in a row. The stuff bits permit the receiver to stay in sync with the transmitter and not drift into mis-interpreting the data.

CAN Software in the mbed

Understanding CANMessage is essential to using this well. It accepts up to 5 parameters; the 3 shown in the example below are:

• 1337 - a [randomly] selected identifier for the message. In the default mode of this message, this is an 11-bit value.
• &counter - starting address of the block of data to send, which happens to point to the only byte being sent.
• 1 - the number of bytes to send, which are accessed at the fore-mentioned address.

can1.write( ) returns true if the message was successfully sent (network good, outbound buffer not full, etc)

#include "mbed.h"
 
Ticker ticker;
DigitalOut led1(LED1);
DigitalOut led2(LED2);
CAN can1(p9, p10);
CAN can2(p30, p29);
char counter = 0;

void send() {
    printf("send()\n");
    if (can1.write(CANMessage(1337, &counter, 1))) {
        printf("wloop()\n");
        counter++;
        printf("Message sent: %d\n", counter);
        wait(0.2);
    } 
    led1 = !led1;
}

And then for a look at the while loop - you see it will [wastefully] print "loop()" and it will [wastefully] wait(0.2), so if you were working a busy network, both of these would be not such a good idea. On the other hand, without those delays, this node would attempt to "storm the bus" with the message '1337', and perhaps not leaving much room for other traffic.

Now to the receiver -

In the middle is the if (can2.read(msg)) which fills in msg and returns true if one has been received. Very likely you will expand on the printf, in order to print the identifier, perhaps the number of bytes of data, and then each byte in that packet.

int main() {
    printf("main()\n");
    ticker.attach(&send, 1);
    CANMessage msg;
    while(1) {
        printf("loop()\n");
        if (can2.read(msg)) {
            printf("Message received: %d\n", msg.data[0]);
            led2 = !led2;
        } 
    }
}

Shown in the example, the two ports simply talk to each other, one as a transmitter and the other as a receiver. In a more practical application, you may only need one of those CAN ports, which you connect to some other system (e.g. car OBD-II port). When connecting to some other system, you should leave the resistors off the circuit - they will already be present in that other system.

The next very important item when connecting to some other system is to connect at the correct communication bit-rate. Use the can1.frequency( ) api to set the bit-rate.

CAUTION If you set one node to an incompatible bit-rate with the network of interest, it can bring the whole network down! Autobaud is not part of CAN, although it can be accomplished in software.

References to more on CAN

• Handbook - CAN contains some of this same information, and a bit of discussion.
• Books about CAN are quite plentiful, many focused more specifically on an industry.
• mbed Baseboards, many of which support CAN.
• Software supporting CAN communications, this one runs on my favorite baseboard.

Protocols commonly used

• CANopen - manufacturing process control
• OBDII - automotive diagnostics
• SAE J1939 - off road truck and bus
• ISO 11783 - agricultural
• NMEA 2000 - GPS and navigation