CAN Bus Project part 4 : How CAN works

This is part 4 in my project to get my Arduino and TI Tiva Launchpad talking CAN.

Today, I want to say a little about how CAN works.

You don’t need to know today’s stuff to get a CAN link working. If you don’t care about details and just want things up-and-running that’s cool. Skip this post and go on to the next where I’ll continue listing Arduino CAN code. 

Personally I find CAN super-elegant however, and can’t resist looking under the hood now-and-again. So, for those like me, here goes:

A CAN network is two wires ('CANH' and 'CANL') and a couple of 120ohm resistors. Devices wanting to use the network hang off the wires. 

All devices on a CAN network have equal rights – none is an overall master.

CAN has an unusual way to send 0’s and 1’s. Figure 2 shows the idea. 

To send a ‘0’, a device pulls the CANH wire to a high voltage (typically 3.5V), and at the same time pulls CANL low (to typically, 1.5V). 

To send a ‘1’, CANH and CANL are both pulled to the same, intermediate, voltage (2.5V say).

It’s a CAN rule that a device sending ‘0’ strongly drives the wires to their required (3.5/1.5V) levels. 1’s are only weakly driven however. This has consequences when two devices try to talk at the same time: Suppose some device on a CAN link tries to send a ‘0’ at the same instant as another device tries to send a ‘1’. The device sending ‘0’ drives CANH/L hard, while the device trying to send 1 drives weakly. The result is ‘0’ wins. In the jargon of CAN, 0’s are dominant, 1’s are recessive. 

It’s another rule of CAN that if a device tries to send a ‘1’ and finds itself drowned-out by a device that’s sending a ‘0’, the device sending the ‘1’ must immediately stop talking, and stay silent for a time.

This dominant / recessive business has real-world uses: Picture two sensors in a car, one monitoring aircon temperature and a second to tell you your brakes have failed (!). By having the brake-sensor send messages that begin “00…”, and the aircon sensor “11…”, you guarantee that if ever both sensors try to talk at the same time, it’s the brake-failure messages that dominate. 

If you add a third sensor (headlamp brightness, say) that sends messages starting “01…”, then these are guaranteed to be heard over aircon messages, but will be drowned-out by brake sensor messages. Elegant, huh?

In fact, rather that two bits, CAN gives you eleven bits at the start of your messages to set message priority (/ identity). Car junkies know all about such things. Cars these days have CAN (OBD) sockets (normally in the foot-well). You can plug in and watch the CAN messages flying around.

O.k., we’ve sketched out the way CANBus handles message priority. This is only one nice feature of CAN however. CAN also has multiple ways to monitor for network errors:

When you receive a CAN message you get up to 64-bits of message data. Along with these come 11-bits that form a so-called CRC checksum. Understanding CRC’s gets math’y and I don’t want to go into them here. Suffice to say they allow you to check  for (and partly correct) errors in the message. 

CANBus also has mechanisms to synchronize the timing of different devices on the network, and more stuff besides. There are some good application notes from the likes of Microchip, TI etc. that tell you more, and for the complete picture there’s the official ISO 11898 specification.

One last point: Part of CAN’s success is that communication can be entirely handled at the hardware level. (Industry has come up with various software standards such as CANOpen that sit on top of CAN, but they’re a story for another day). No software means no software bugs – one reason for CAN’s popularity in safety critical systems.

O.k., enough theory, next post I’ll get back to the practical business of getting my Arduino to talk CAN.