Intro to CAN (Controller Area Network)

CAN is the system that ties the entire car together. It's like a LAN network but for cars, and our boards use it to talk to each other.

CAN was designed as an automotive communications protocol, so it's very robust and great for our purposes. It defines both physical and low-level standards, allowing us to define our own high-level protocol on top of the barebones protocol provided. The protocol is designed for sensor networks, where each node broadcasts data autonomously and doesn't really care if that data was received. For more information, the Wikipedia article is pretty good.

Overview

For normal high-speed CAN, the following core concepts are defined:

• Differential signalling: We use the difference between the values of a balanced pair to represent our logic values, improving noise immunity and the ability to handle different grounds or logic voltages.
• Linear bus topology: A CAN bus should be linear with short stub nodes along the bus and an end node at each end, usually terminated with 120 ohm resistors.
• Message-based broadcast: Data is broadcasted to the entire network as fixed-length packets where the ID determines its priority.
• Multi-master bus: All nodes act as masters and do not distinguish between specific message sources or destinations.
• Error detection: CRCs are used to verify message integrity and error frames alert nodes of network errors.

As far as we're concerned, a CAN frame consists of an identifier and up to 8 bytes of data. The rest of the frame is actually used for things such as a data checksum and control bits, but we don't need to worry about them.

There are two types of identifiers, standard (11 bits) and extended (29 bits). The lower the ID, the higher the priority. This is accomplished through the concept of "dominant" (logic 0) bits where the differential is actively driven apart and "recessive" (logic 1) bits where the differential is returned to around 0V. From Wikipedia:

The CAN specifications use the terms "dominant" bits and "recessive" bits where dominant is a logical 0 (actively driven to a voltage by the transmitter) and recessive is a logical 1 (passively returned to a voltage by a resistor). The idle state is represented by the recessive level (Logical 1). If one node transmits a dominant bit and another node transmits a recessive bit then there is a collision and the dominant bit "wins". This means there is no delay to the higher-priority message, and the node transmitting the lower priority message automatically attempts to re-transmit six bit clocks after the end of the dominant message. This makes CAN very suitable as a real time prioritized communications system.

High-Level Protocol

We've defined our own high-level protocol for MSXII by dividing the standard identifier into message ID, type, and source device. The general idea behind our protocol is to take advantage of CAN's broadcast-based system and have nodes perform actions based on the messages that they receive, regardless of the source device. By defining the message ID in the most significant bits and the source device in the least significant bits, the source device has almost no effect on the frame priority. Since that information is transmitted mostly for telemetry, our chunking accurately reflects the effect each field should have on a frame's priority.

Although most CAN messages will be broadcasted openly, there are some messages that must be processed by all appropriate systems, such as a BPS fault. Critical messages are defined as events that will result in an unrecoverable failure condition if not processed. To ensure that these messages are processed, we define acknowledgements (ACKs) as a response to critical messages. When a critical message is received, an ACK must be sent as a reply with the same message ID and the type field set to ACK. Currently, an ACK's data field is unused.

One option we're currently exploring is using the remote transmission request (RTR) bit to represent ACKs. Unfortunately, the CAN standard defines frames with the RTR bit set as remote frames. These frames are used to request data to be sent to a destination device and do not contain data fields. Instead, the data length code (DLC) represents the data length of the expected response. Using the RTR bit to represent ACKs would be misusing the protocol.