Introduction
The Celtic Engineer is a weekly newsletter produced by Celtic Engineering Solutions. We hope you enjoy it. If you have any suggestions for topics, would like to give feedback or want your email added to the distribution list please send an email to [email protected].
Controller Area Network – CAN
The CAN bus started almost 35 years ago as a way to communicate between the ever increasingly complex automotive subsystems. Currently there are two versions of CAN in use: CAN 2.0A uses an 11-bit identifier and CAN 2.0B uses a 29-bit identifier. If you grew up in the early days of automobiles, everything was hard wired together, but todays cars have over 70 separate embedded systems referred to as Electronic Control Units or ECU’s. These systems often must communicate with one another and the way they do that is by using the multi-master system known as CAN bus.
To better understand why one system needs to communicate with another, in a car, here are a few examples:
- Hill hold function. This is when a car on a hill will not roll backward while you are waiting for a light, even if you take your foot off the brake. To accomplish this, the control unit receives information from the rotor speed sensor to know when the car is at a standstill. It also receives information from the cars tilt sensor to know when it is on a hill. Lastly, it communicates with the braking system to hold the car in place.
- Consumer Safety systems. A safety system involving the brakes uses input from the seat belt system to know how many seats contain passengers and if their safety belts are fastened. Some cars will not release the brakes until everyone is buckled up.
Let’s wire this up
Many masters can connect to the CAN Bus. The bus itself is a differential system, CAN_HI and CAN_LOW. When not in use they sit at 2.5V (for high speed CAN). When a signal is transmitted, the CAN_HI is elevated toward 5V while the CAN_LOW is pulled toward ground. There is a 120 ohm resistor used at each end of the Bus to minimize reflections.
Modern CAN Bus controllers make using can very simple. While the generation of the CAN Frame – arbitration, data length, ID, stuff bits and CRC can be daunting, all of that will be handled by the control chip and is invisible to the user, i.e., the MCU. The interface between the MCU and the CAN Controller can be serial (UART), SPI, I2C or parallel.
When you send data to the CAN controller, it does all the framing. It sets up the fields and transmits the data according to protocol. The CAN receiver strips all the required information away from the data and passes that data to the MCU.
What is bit stuffing
CAN bus is an asynchronous bus. In order to maintain synchronization with the bits, there must be a transition every so often so the controller knows how much time each bit requires. If the bits being transferred do not change often enough, every 5 bits, the controller will add a bit of the opposite polarity. These stuff bit are automatically removed by the controller on the receiving end. Thank goodness, right?
CAN Peripheral
Many modern microcontrollers have CAN peripherals as part of their feature set. When using one of these peripherals, it is not necessary to use an external CAN controller chip since that is already contained inside the MCU.
Final thoughts
This newsletter is sponsored by Celtic Engineering Solutions LLC, a design engineering firm based out of West Jordan, Utah, which can be found on the web at: www.celticengineeringsolutions.com. You can find the newsletter on the company blog, LinkedIn or by subscribing. Send your emails to The Celtic Engineer at: [email protected].
