Skip to content

electrical comm can

Grant Geyer edited this page May 24, 2021 · 5 revisions

CAN

Controller Area Network

Part of Communication Protocols.

Property
Use Communication between microcontrollers
Wires 2 - CAN High and Low (also TX and RX to/from transceiver)
Clock No clock
Drive Differential
Bus Yes
Data rate 1 Mbit/s
Usual lengths Up to 40 meters (at 1Mbit/s)

Disclaimer: We use high speed CAN with two terminations (not low speed, fault tolerant) and this page is written to describe that variant.

CAN stands for Controller Area Network. It was developed in the 1980s for automotive use to meet the specific demands of vehicle systems. It has since undergone several revisions and expanded to many other uses, a testament to its many advantages.

I recommend you first read and understand I2C as it is often worthwhile to compare CAN to it and I will do so frequently.

CAN is designed to function in a high noise environment with multiple devices trying to talk at the same time with different levels of priority. Another focus of the design was a singular bus so it would be easy to connect new devices or to tap into it and debug.

Wiring

The CAN bus itself has a CAN High and CAN Low wire which make up a differential pair. At each end of the bus, there is a 120 Ohm terminating resistor between the two to prevent signal reflections. An improved version (which we use) has two 60 Ohm resistors with a capacitor between the resistors and ground in place of the single 120 resistor. The CAN High and Low signals are driven by dedicated CAN transceivers. Devices like microcontrollers and raspberry pis will talk to these transcievers with through a CAN TX and CAN RX signal, either directly or indirectly with an IC like the MCP2515. Differential signals are more noise immune so it is important to keep the traces close on a PCB with minimal space in between and keep wires close, ideally twisted. Both should be kept close to the same length to avoid skew.

CAN Messages

CAN messages are transmitted on the bus with 1s (reccessive) and 0s (dominant). When no transceiver drives the CAN lines high and low and instead leaves them floating, the termination will bring them to the same voltage of half VDD; this is known as a recessive bit. When a transceiver drives high high and low low, a dominant bit is put on the bus. Dominant bits will dominate (for lack of a better word) recessive bits and be put on the bus. This allows for multiple devices to try to talk on the bus without fighting each other and causing damage. Messages with a lower ID (and more 0s/dominant bits) will resolve earlier and thus have a higher priority. This is similar to the open drain nature of I2C and the address resolution phase of it.

CAN messages have several components:

  • ID - Unlike I2C where each IC on the bus has it's own ID, each CAN message has its own ID. Much like I2C, multiple bus transactions may be started at the same time, and the lower address will "win" due to more dominant bits. Addresses are 11 bits in regular CAN and 29 bits in extended ID CAN.
  • Data - 8 bytes of data are sent in every CAN message.
  • CRC - A 15 bit CRC is made for receivers to check that all data was transmitted and received correctly.
  • ACK - Unlike I2C where a slave device which the address ACKs to confirm they got the message, every device on the CAN bus ACKs a message to indicate the message was sent correctly and they received it. Remember, messages have IDs, not ICs.
  • (other)

Bit stuffing: In any asynchronous protocol, the different timing of transmitter and receiver clocks is also a concern. If one device sends 8 lows, a receiver may read that as 7 or 9 lows. In UART, this is mitigated by sending single bytes at a time with start and stop bits. In CAN with longer messages, bit stuffing is used (bit stuffing is also used in USB). If 5 of the same bit (dominant or recessive) are sent in a row, the a bit of the opposite value (recessive or dominant) is always sent after the fifth so that the timing between sender and receiver is maintained.

ROV's Use of CAN

IDs / addresses
ID Use
0x201-0x203 ESC control messages from Pi to quad ESCs 1-3
0x204 Solenoid control messages from Pi
0x206 ESC control messages to an ESC not in the system
0x301-0x303 ESC telemetry info from microcontrollers
Common Issues
  • No buffer space available -

References:

Clone this wiki locally