Controller Area Network (CAN, "can") is a serial broadcast communication protocol. This means that different microcontrollers (uCs) on a device use it to communicate with one another. CAN is very popular in the automotive industry because of its speed and reliability. On EVT, we use it for exactly that, communicating between uCs on boards around the bike. As a team, we also follow the CANopen standard, which is a higher-level protocol that expands on CAN. More information about CAN can be found on Wikipedia.
Unlike many other communication protocols/standards that we use, CAN does not primarily center two boards communicating with one another. CAN does not establish any "master" or commander board. Instead, every device on the CAN network essentially shouts out any message it has to every other device on the network. Then, any boards that care about that message will parse the data from it and do with that what they will. On EVT, we use the CAN 2.0 standard, which is one of the simplest CAN standards.
Messages have essentially two parts: the identifier and the payload. The identifier can be up to 11 bits, or with an extended frame (which is simply a frame with a longer identifier), up to 29 bits. The payload can be up to 8 bytes. There are other parts of the message, including CRC bits, bit stuffing, and other features, but that's beyond what is typically necessary to know.
Nothing internal to the message specifies HOW the data in the message should be interpreted. Instead, accompanying documentation will describe what the payload of a message with a specific ID will be. Oftentimes this documentation is in the form of DBC (Database CAN) files, which is a file format that simply maps CAN ids to their data layout and other useful information like their name or purpose.
Whenever a CAN message is received, an interrupt is triggered and a user-defined interrupt handler is invoked. This interrupt handler typically just shoves the CAN message into a queue to be processed later. If the messages in the queue are not processed fast enough, the queue will have CAN messages added to it at a higher rate than the CAN messages that are removed from it, which will not only mean that whatever is processing the queue is mostly working with old, outdated data, but also that new information eventually will just be unable to be added to the queue. Thus, it is important that the speed of processing messages always outpaces the speed of receiving messages.
Each CAN bus can have many nodes on it, each of which is normally one of the team's circuit boards. Each uC on a circuit board interacts with the bus via a transceiver on its board. The uC is connected to the transceiver by two wires CAN TX and CAN RX. The wires work very differently from and should not be confused with UART's TX and RX. CAN TX is used by the uC to transmit messages, and CAN RX is used to receive messages. For outgoing messages, CAN transceiver converts CAN TX to CAN High and Low, which is sent to other transceivers around the bike. For incoming messages, the CAN transceiver, converts CAN High and Low to CAN RX, which is sent to the uC. CAN TX and RX need pull-up resistors, and CAN High and Low need terminating resistors. An example block diagram for CAN communication is shown below.
All CAN communication is handled with CAN frames. Each CAN frame consists of and ID, a data length, some data, and a Cyclic Redundancy Check (CRC). All nodes on the bus can send a frame whenever the bus is not busy, and all nodes can receive every message sent on the bus. Nodes can filter out frames with certain IDs to limit how many frames need to be processed.
The image below is a screenshot from Logic, the Saleae logic analyzer software. See Saleae Logic Analyzer for more information. The screenshot shows parts of two CAN frames, including data, a CRC, and an ID on CAN RX. There is also a brief toggle on the CAN TX wire, but this is likely an error.
If your CAN TX messages are not showing up, there is likely an electrical problem between the uC and the transceiver. If CAN RX messages are not showing up, check CAN High and Low with the PEAK Can Dongle or an Oscilloscope to confirm that those signals are formed properly.
Below is an example of what CAN High and Low might look like when sending a data frame over CAN. The blue line shows the voltage on CAN High, and the red line shows the voltage on CAN Low. This is what the output should look like when probing these wires with an oscilloscope.
If the voltages on CAN High and Low are not mirrored as they are in this image, there is an issue with the CAN bus. Normally, this is either a soldering or bus impedance issue. Be sure to use the FUN-E SNAIL to debug issues with the bus.