The Controller Area Network is a bus that can connect many devices, called nodes. When a node sends data on the bus, it broadcasts it. It identifies itself, but not the recipient. Only once node may transmit on the bus at a time.
The CAN specification didn't originally define the physical layer, but since then a standard has been adopted and is in wide use.
The CAN bus itself is a single long cable, which CAN nodes connected very close to the cable. For instance you wouldn't have any cables coming off the main cable - just very short "stubs" to connect to each device.
The cable itself consists of a single differential pair, typically twisted, with a characteristic impedance of 120 ohms. The far ends of the cable are terminated with 120-ohm resistors.
Typically a ground wire is also provided, and to prevent ground loops and reference voltage differences it should be the only ground reference used. Some CAN transceivers are isolated to get around this limitation. Power is also commonly provided. A connector is not part of the physical layer specification, but the DB9 connector is common.
There are two electrical states - dominant and recessive.
In the recessive state, no node (CAN device) drives the bus. Since both ends of the long cable are terminated (120ohm resistors across each end), the voltage across the differential pair quickly falls to zero.
In the dominant state, one end of the differential pair, called CANL, is pulled low, while the other end, CANH, is pulled high (generally 5V or 3.3V). Naturally this overrides the recessive state, and this the name.
Similarity to single-ended, pulled up bus
This situation is somewhat analogous to single wire bus where the bus is pulled up with a resistor resistor (recessive), or pulled down by a device (dominant). Its purpose is to provide access to a shared medium in such a way that multiple devices with conflicting bit states will not short each other.
Since the CAN bus is a differential pair, typically a CAN transceiver is employed between a microcontroller (or FPGA, ASIC, etc.) and the CAN bus.
On the "microcontroller side", there are typically two connections - an input and an output. The output always reports the state of the CAN bus - 0 for dominant, and 1 for recessive.
The CAN transceiver's input is how you tell the transceiver to actually talk on the bus. A 0 will cause the transceiver to assert a dominate state on the bus, and a 1 will cause a recessive state.
The recessive state on the can bus is where the voltage across the differential pair (CANH - CANL = 0V) is zero. This corresponds to the logic 1 state.
The dominate state on the CAN bus is there where there is voltage (5 or 3.3V) across the differential pair (CANH - CANL = 3.3/5 V). This corresponds to the logic 0 state.
Notice that once you are on the microcontroller side, the IO voltages do match the logical states (positive logic). In other words, on the microcontroller side, 0V is logic 0 and 5/3.3V is logic 1. It looks very similar to CMOS-level serial in that the idle state is 1.
Bits on the bus
Bits are put on the bus in the same manner as RS-232 style asynchronous serial - each bit has a certain time on the bus before the next one's turn. The bit rate can vary, but 1Mbit is common (1µs per bit).
When no nodes are transmitting, the bus is idle. This is the recessive state.
A transmission starts when a node asserts a dominant state on the bus. The first bit is the SOF (start of frame) bit, and is analogous to the start bit in RS-232 style serial. Additional bits follow. We'll talk about the structure of this data a little further down.
Asynchronous Serial and timing drift.
Whenever a bit changes - from a 0 to a 1, or a 1 to a 0, there is an opportunity for a receiver to resynchronize -- to clear out any timing error that has built up between the transmitter and the receiver. However, the longer the time period between transitions, the more timing error can build up. If many 0s (or 1s) are sent in succession, timing error could easily exceed design margins. RS-232 style serial solves this problem by forcing transitions between bytes (the start and stop bits). CAN resolves the problem by using "bit stuffing".
Bit stuffing is a method to make sure there are never any more than a specified number of bits that are exactly the same in a row. In other words, it forces there to be a minimum number of transitions in a data stream - so that the receiver can be guaranteed a worst case resynchronization gap.
If 5 zeros are sent in a row, CAN requires that a 1 be sent next. This extra bit will be thrown away by the receiver.
If 5 ones are sent in a row, CAN requires that a 0 be sent next. This extra bit will be thrown away by the receiver.
Remember that even if the next bit in the data would cause the needed transition - the receiver won't know that. You must insert the extra bit.
There is one gotcha worth mentioning. 0 0 0 0 0 will be followed by a stuffed 1. Let's say another 4 1's then follow. Does that count as 5 ones, or 4? It counts as 5 - so yes, we would then stuff a 0. Remember that the point is to limit the time we can go without seeing a transition.
If a receiver received 6 consecutive bits in a row, this is considered an error and it throws away any subsequent data.
Everything in CAN is sent in a frame (or message). This is essentially a packet. It consists of the sender's unique ID, some flags, some data, and a CRC.
Standard and Extended frames
There are two versions of the CAN frame - CAN 2.0 A and CAN 2.0C B. CAN 2.0 A uses 11-bit identifiers (standard frame), and CAN 2.0 B uses a 29-bit identifier (extended frame).
The identifier of a given node must be unique on the bus.
DATA and REMOTE frames
A DATA frame's identifier is that of the sender (transmitter). The frame can contain up to 8 bytes of data.
A REMOTE frame's identifier is that of another device - a device that the sender is requesting data from. REMOTE frames do not contain any data bytes.
A single bit, the RTR (remote transmission request) bit determines if a frame is DATA or REMOTE.
Standard (11-bit ID) frames
The CAN DATA frame starts with the SOF - start of frame - bit. This is analogous to the start bit in RS-232 style asynchronous serial. It is the bit require to transition from idle to non-idle. The SOF bit is a logic 0 (dominant).
Identifier field (11 bits)
The identifier is the ID of the sender. Every CAN node must have a unique identifier.
RTR - remote transmission request - is a single bit that indicates if this is a DATA frame (0, dominant) or a REMOTE frame (1, recessive) .
The IDE - Identifier extension bit -- must be 0 (dominant) for 11-bit identifiers.
The r0 - reserved bit 0 - must be set to 0 (dominant) by senders - but ignored by receivers.
DLC field (4 bits)
The DLC - data length code - field indicates how many bytes of data this frame will contain (0-8).
Data field (0-8 bytes)
This is the data the DLC field told us to expect.
CRC field (15 bits)
This 15-bit CRC is used to check for any errors in the received data.
This single bit space is an opportunity for any receiver(s) to provide acknowledgment. The sender sets the recessive state, and any number of receivers may overwrite this with a dominant state.
This single bit is always a 1 (recessive).
END of Frame (7 bits)
The END of frame is simply a sequence of 7 recessive bits. This provides padding so that a recently attached device can tell that the frame has ended. Recall that 6 or more sequential bits of the same state is an error - the END of Frame is a deliberate error, which acts as a frame synchronization event. Note that the END of Frame is not bit stuffed, as that would defeat its purpose.
Extended (29-bit ID) frames
The frame starts with the start of frame bit (SOF). This is the same as in standard frames.
Identifier A (11 bits)
This is the first 11 bits of the 29-bit extended frame identifier.
SRR - substitute remote request - is always a 1 (recessive) in extended frames.
The IDE - Identifier extension bit -- must be 1 (recessive) in extended frames.
Identifier B (18 bits)
The next 18 bits of the 29-bit extended frame identifier.
The RTR - remote transmission request bit is 0 (dominant) if this is a DATA frame, or 1 (recessive) if this is a REMOTE frame.
r0, r1 bits
r0 and r1 are reserved bits. Senders must send 0s (dominant), and receivers must accept any state.
DLC field (4 bits)
The DLC - data length code - same as in standard frames.
Data field (0-8 bytes)
This is the data the DLC field told us to expect. This is the same as in standard frames.
CRC field (15 bits)
This 15-bit CRC is used to check for any errors in the received data. This is the same as in standard frames.
This single bit space is an opportunity for any receiver(s) to provide acknowledgment. This is the same as in standard frames.
This single bit is always a 1 (recessive). This is the same as in standard frames.
END of Frame (7 bits)
The END of frame is simply a sequence of 7 recessive bits. This is the same as in standard frames.
CAN nodes listen to the bus, and will only attempt to transmit frames if the bus is idle. As soon as the bus becomes idle, however, multiple nodes may attempt transmission simultaneously.
Since dominant (0) wins out over recessive (1) on the CAN bus, an individual node can check to see if its recessive bits are indeed recessive. As long as they are, then it may continue transmitting.
If a node detects a dominant (0) bit when it has attempted to send a recessive (1) bit, it stops transmitting, and yields to the other node(s) until idle.
Note that that the frame identifier therefore is related to the priority of the frame. Frame identifiers will be chosen such that high priority devices will win arbitration over lower priority ones.
Example CAN Devices
trello ID: 57215d59658a3abf8cf6f277