Synthesis Studios

Last week, a new version of the Linux kernel was released. Amongst the speculations about how fast ARM chips and new spinlocks will change the world was the inclusion of a new networking protocol. Many people, including some big reviewers, have glazed over CAN as a simple protocol designed for industry. This does not give it justice. CAN is fundamentally different from the IEEE 802 protocols in that it addresses the data contained within the packet instead of the intended recipient.

By looking at these protocols from a different perspective you can see where many of the common communications ideas like handshaking and retransmission don’t fit.

Think about it for a minute. It’s a fundamental difference in transportation method. Imagine Ethernet as a phone call saying “This packet is for Aaron’s phone,” and CAN as a radio station saying “This packet contains Billy Joel.” By looking at these protocols from a different perspective you can see where many of the common communications ideas like handshaking and retransmission don’t fit. Just jumping into CAN with these notions can (sorry!) leave someone very confused and frustrated, like the kernel network maintainers.

CAN was designed by Robert Bosch GmbH in the late eighties for device communications in noisy environments. It is designed to disseminate information about the entire region covered by the network to every node in the network with little overhead. Consider a network that covers a car, a common use for CAN, you have many sensors and many devices that wish to talk to each other. In a connection oriented network, this would involve much overhead; everyone who is interested in the status of the ABS system would have to either ask the ABS how it’s doing or hope the ABS speaks up. This is especially time-consuming in an emergency situation. In a pre-crash situation, many devices are going to need to know about the ABS’s activity in a short amount of time. This problem gets even worse when there are many devices all looking for several pieces of data.

CAN has a very clever way of arbitrating who gets to talk on the network. Carrier Sense Multiple Access with Bitwise Arbitration (CSMA/BA) allows the devices to pick who will transmit next just by saying their ID. This makes it especially important to pick the IDs of the data properly. You want a tire pressure monitor’s warnings to supersede the status of the rear defroster in an emergency. By allowing higher priority data to block the transmission of lower priority data a CAN network does have the possibility for a lower priority node to get starved of transmission time.

I hope these point help anyone who reads this to realize that CAN is not a direct replacement for Ethernet, even if the powers that be decided to add some hacks (like ISO-TP) to let you use it in that manner. Hopefully its inclusion in the Linux kernel will cause more communities (i.e. sensor networks and home automation) to pay attention to what network protocols they are using and why.