A Small CAN of History

CAN is short for Controller Area Network. It was originally created by the Robert Bosch company. CAN networks have found their home mostly in vehicles where they’ve been used since the late 1980s.

The first vehicles to use CAN were expensive luxury cars like Mercedes. As the average vehicle grew more complex and found itself stuffed with more and more electronics, CAN migrated to more ordinary vehicles.

CAN’s cousin, LIN (Local Interconnect Network) is newer and used for less critical subsystems where data transmission speed and reliability are less critical such as air-conditioning and infotainment.

CAN is designed for more critical systems like engine control, anti-lock brakes, parking assist etc.

What Can You Do With CAN Networking?

We’ve already mentioned that CAN is found in vehicles, so if you’re brave enough to connect something to the CAN bus in your car, that’s one possible use.

A safer and more sensible way to use it would be in applications like robotics. CAN is robust and combats EMI (electromagnetic interference), something which motors are known for.

CAN is also well suited for short message applications.

You can create your own CAN network using a CAT 3 twisted pair cable (telephone wiring) and a microcontroller with built-in CAN capabilities like the PIC18F2685 or some similar variant.

This is an introductory post, so the details on how to do this are beyond the scope of this writing, but you need to crawl before you run, so let’s go over some CAN networking basics.

CAN Bus 101

The CAN bus consists of 2 wires CAN high (CANH) and CAN low (CANL). Anything attached to the wires is referred to as a node.

Above is a sketch I did by hand a while back of the topology of a CAN network.

My handwriting and artistic skill aren’t great, but you can get a good idea of how the network is set up from the picture. The nodes at the ends are terminating nodes. Try to keep the wires that connect a node to the CAN bus short.

Become the Maker you were born to be. Try Arduino Academy for FREE!

Terminating nodes are special nodes that are either simply a 120Ω resistor, or better yet, 2 60Ω resistors with a bypass capacitor in between them. You need terminating nodes. Without them, CAN frames will leak out and fall on the floor 😉

Another un-artistic sketch, this one of the terminating nodes, is shown below.

CAN doesn’t use any formal addressing; every node on the CAN bus receives every message every other node sends. Also, any node on the bus can talk to any other node on the bus.

CAN busses can operate at a maximum speed of 1Mbps if the wiring is less than 40 meters. For runs longer than 40 meters (up to 500 meters) the speed drops to 125Kbps.

CAN-speak refers to logic level 0 signals as “dominant” and logic level 1 signals as “recessive.”

If one node transmits a dominant bit and the other node (assuming only 2 nodes) a recessive bit, the dominant bit wins. The node that transmitted it now has control of the bus.

You may be wondering what happens when 2 or more nodes transmit a dominant bit at the same time.

Good question…

CAN Bus Error Handling

CAN uses a form of arbitration known as arbitration on message priority or AMP. This is accomplished by the use of pre-programmed identifier bits in the message which identify the priority of the message.

So, when any CAN node takes the bus to a dominant (logic 0) state, all the nodes see this on the bus. Since the bus is wired in an AND configuration, it is forced low even if other nodes transmit a high signal.

Recall that each node listens to all the other nodes. Each node also knows what it’s transmitting, so if a node is transmitting a 1 but sees a 0 on the bus, then it knows that there is a conflict, or contention on the bus.

If all other nodes are transmitting 1s (recessive) then the node transmitting a 0 (dominant) automatically wins arbitration. The other nodes re-queue their messages for later. In other words, the first node to transmit a 0 on the bus wins exclusive access to the bus.

What if 2 or more nodes attempt to transmit a 0 at the same time?

Recall that each node is pre-programmed with an identifier. This identifier is part of what’s called the arbitration field and is usually 11 bits long (the extended version has 29) and the lowest numbered identifier has the highest priority. That way if 2 or more nodes transmit a 0 at the same time, the node with the higher priority wins.

This makes sense. Consider the following scenario: the ABS sensor senses that the rotors are about the lock while the node associated with engine coolant temperature senses an increase. Since being able to stop the car and avoid an accident is momentarily more important than the coolant temperature being slightly high, that node would have a higher priority and win the arbitration.

Still confused? Take a look at the picture below (taken from Wikipedia).

Say the node associated with the ABS system is Node 15 and the one associated with the coolant temperature is Node 16. Take a look at the ID bits field. Node 15 is pre-programmed with a higher priority (bits 4-10 are 0s), while node 16 is pre-programmed with a lower priority (bits 5-10 are 0s, bit 4 is a 1). Because of this, transmission is stopped for node 16 when bit 4 is reached while node 15 continues.

CANned Frames

The picture below should clarify this even further. This is a representation of a typical CAN frame. The frame includes whatever data a node is transmitting with all the control bits.

The SOF bit is the start of frame bit and is also used for synchronizing the nodes. It is dominant.

Next comes that 11 bit identifier we’ve been talking about.

RTR is also part of the arbitration field along with the identifier. RTR stands for remote transmission request. We’ll talk a bit more on this later.

Then comes the IDE (identifier extension) bit. When this bit is dominant (logical 0), a standard CAN identifier with no extension transmits. If it’s recessive, then 18 more bits will follow it for a total of 29 bits. For our purposes, we’ll stick with the standard 11 bit identifier from here on and say no more about the extended version. Just know that it’s out there and you may run into it if you work with CAN.

The next bit, r0, is reserved for future use.

Following that comes the DLC or data length code field which is 4 bits long. The data field within a CAN frame can hold up to 8 bytes, so that’s why the DLC field is 4 bits long. It represents the number of bytes that are going to be transmitted.

CRC stands for cyclic redundancy check. This field is 16 bits long and serves as a checksum that can be used to detect errors in the data.

The next bit, ACK, is an acknowledge bit so the sending node knows the receiving node got an error free message.

After that comes the end of frame or EOF bit which signifies the end of the CAN frame. This field also disables bit-stuffing, which is a more advanced topic that I may discuss in a future post.

The last field stands for inter-frame space. It is there because a short amount of time is required to correctly move messages around. It is 7 bits long and contains the amount of time the CAN controller needs to move the actual message to the buffer.

Four Types of CAN Frames

The RTR bit is now back to haunt us…

There are actually 4 types of CAN frames.

The data frame we just dissected is the most common. There are also remote, error, and overload frames.

The remote frame is just like the data frame, except that the RTR bit is recessive and there’s no data. This type of frame is used to solicit information from another node. In this case, the identifier field identifies the node which is to provide the requested information.

The error frame is a special one that violates the formatting rules for CAN messages. It is an error in itself, and transmits when a node detects an error in a message, causing all other nodes to also transmit an error frame. The node that originally transmitted the message with the error in it then re-transmits the message.

Finally, the overload frame transmits when a node is busy and needs more time in between messages.

You CAN Do It

Whew, that’s a lot to take in and this is just an introduction to CAN!

Don’t let is scare you from experimenting with the CAN network though. Also remember that CAN can be used in other places besides vehicles; CAN has excellent immunity to noise and EMI.

If you connect a device to the CAN network in your car BE CAREFUL and 100% sure everything is right. Of course, I do not condone connecting anything to the CAN network in your vehicle and assume no responsibility for any type of loss or injury should you choose to do so.

CAN bus network topology can also drastically reduce wiring, thus further reducing noise caused by things like parasitic capacitance and inductance.

There is so much more to CAN than what we’ve covered here. A blog post can only hold so much, so maybe we’ll pick it up in the near future.

Until then,

Happy Soldering!

Become the Maker you were born to be. Try Arduino Academy for FREE!