CAN BUS Tutorial

From Embedded Systems Learning Academy
Revision as of 21:32, 2 October 2013 by Preet (talk | contribs)

Jump to: navigation, search

CAN BUS

This article is under construction
CAN BUS (Controller Area Network) is a very deterministic BUS heavily used in the automotive industry. It is a half-duplex BUS, that operates using a pair of differential signals. Typically, the speed standards are 100K, 250K, 500K or 1Mbit.

CAN BUS Frame

A CAN frame may contain 50-114 bits which includes data bits like message id, the real payload (0-8 bytes), and some CRC bytes. After the hardware captures the CAN frame, it stores it into a simpler frame that contains frame information, message id, and the data bytes.

A CAN frame may contain one of two message id types :

  • 11-bit
  • 29-bit

   | Frame Information            | Message ID   | 0-8 bytes |
   | RTR, Msg ID Type, Byte Count | 11 or 29-bit | 0-8 bytes |

  • RTR : Remote transmission frame
    This bit indicates to the destination that an empty message is being sent.
    You can consider this "PING" or a signal to send something back to the source
  • Message ID Type
    This bit (when 1) indicates it is a 29-bit ID or else an 11-bit ID
  • Data bytes
    The payload can be zero bytes, or up to full 8 bytes in a CAN frame.

Message ID

A message ID of a CAN frame is very unique in the sense that it is used as a priority on the physical BUS. A lower message ID has higher priority since logical 0s are recessive and they override logical 1s on the BUS. This is a key feature of the CAN BUS because you can guarantee that your message will get across above everyone else if it has the highest priority.

Another property of the message id is that each node on a CAN bus MUST acknowledge a chosen message id for a message to be successful. If a message is not acknowledged, retransmissions will take place by the hardware, which can eventually lead to "BUS-OFF" state as given by the CAN specifications.

Transceiver

Unlike other BUSes that can be up and running without any external hardware, CAN BUS REQUIRES a voltage transceiver that converts logical Rx/Tx pins into a single differential pair wire that is hooked up on the CAN BUS.


Typical CAN Communication Design

Before the CAN BUS is used in an application, it helps to know some basic characteristics of the BUS :

  • No two nodes shall send the same message ID
    Doing so will cause two nodes to cause collisions on the BUS, since arbitration will not take place.
  • No two nodes shall acknowledge the same message ID
    Doing so will cause two nodes to acknowledge the same packet.

So knowing the above requirements, there is a dilemma for us:

  • How can two nodes send a message to another node using the same message id ?

So what we can do now is split the message id into separate fields :

   | 4-bit destination id | 4-bit source id | 3-bit message id |

What we have done now is added the capability that multiple nodes can speak to each other, and whoever has the lowest source id has the highest priority on the CAN BUS. So suppose that we are a "lights controller" on a vehicle's CAN BUS, then we can specify the following standard :

  • Lights Controller ID: 5
  • Message ID : 1 = Lights command
  • Message ID : 2 = Clear Faults

With this in mind, we would tell our CAN controller to accept the following range of all message ids:

   | 0101 | xxxx | xxx |

Therefore, our CAN acceptance filter is 0x280 - 0x2FF. If we do this, anyone can send us a message, and no two nodes will send the same message id. Likewise, we can send a response message back to anyone using a unique message id.


OBDII

OBDII standard uses CAN BUS to communicate to the ECU. You can connect a CAN controller to an OBDII port easily by using an OBDII to Serial cable. Since this kind of cable doesn't convert the CAN voltage signals to logical signals that a microcontroller can understand, you would also need an MCP2561 based transceiver which would allow your controller to be interfaced to an OBDII port.


Resources

External Resources