Introduction to CAN Bus and SAE J1939 Prototyping

Posted by Wilfried Voss on Mar 20th 2016

This post is part of a series on CAN Bus and SAE J1939 Prototyping with the ARM Cortex M3 processor.

The prototyping of Controller Area Network (CAN) interfaces used to be a tedious task, but the recent years have seen the emergence of low-cost, yet easy-to-use embedded development platforms such as the Arduino, BeagleBone, Raspberry Pi, and others. This opened the door to a myriad of applications for budget-sensitive engineers and hobbyists.

For the longest time the major misconception about Controller Area Network (CAN) was that it is merely used in automobiles. The truth is, CAN, since its introduction in 1986, proved to be a robust, simple and versatile technology and, consequently, CAN found its way into all areas of applications where microprocessors need to communicate among each other.

Along with its undeniably dominant use in automobiles, CAN applications do not only include industrial automation tasks, but any application where distributed control is advantageous and/or a serial bus system will eliminate excessive wiring. CAN proved to be superior to any other field-bus system in regards to low cost, the ability to function in a difficult electrical environment, a high degree of real time capability, excellent error detection and fault confinement capabilities and, almost contradictive to the previously mentioned features, ease of use.

Nowadays there is no special niche for CAN; its use is universal from any industrial application, space and aviation, maritime, medical, down to household appliances such as washers, dryers and even coffee machines.

The performance as well as the price tag of such CAN applications depends primarily on processor power and memory resources. An 8-bit system such as the Arduino Uno may be sufficient for simple CAN applications, but the core question is, why limit the project’s performance from the get-go?

After all, the 32-Bit ARM Cortex-M3 processor series is the preferred choice for Controller Area Network applications due to its internal CAN controllers, sufficient memory (Flash and SRAM) and great CPU clock speed. And yet, ARM prototyping boards are very affordable and most IDEs are free-of-charge.

For this series of posts, I have chosen two very popular systems that both matched my selection criteria, which are low-cost and ease of programming:

Arduino Due - The Due is the first ARM-based Arduino development board. The programming of the microcontroller is accomplished through the familiar Arduino IDE (Windows, Mac), keeping the programming as backward compatible to other Arduino systems as possible, thus allowing a smooth migration between processor systems.

mbed NXP LPC1768 - The mbed Microcontroller was specifically designed for prototyping, and it comes in a 40-pin DIP form-factor, making it ideal for experimenting on breadboards, strip boards and PCBs. The compiler is web-based, and, consequently, it works equally well on Mac, Windows, and Linux.

In the following, I will address the aspects of Controller Area Network (CAN) prototyping using ARM Cortex M3 systems (Arduino Due and mbed NXP LPC1768). My focus will be primarily on providing the basic means to the reader, which includes the description of available resources, hardware and software, and some special insights.

I will explain the basic technical aspects of Controller Area Network and higher-layer protocols such as CANopen, DeviceNet and SAE J1939, the ARM Cortex-M3 Processor, the Arduino Due, and the mbed NXP LPC1768. While a detailed of all these technologies is out of the scope of this book, I will provide references in each chapter that will enable you to gather further details.

All in all, the information as provided will enable you to write your CAN applications within shortest time.

In addition to above mentioned prototyping systems, namely the mbed LPC1768 and the Arduino Due, I will also introduce two systems that we sell through this website. They are:

Throughout this series of posts, I will repeat myself by saying that the mbed LPC1768 and the Arduino Due are without a doubt great systems for CAN Bus and SAE J1939 prototyping, but they do lack one important feature that is mandatory for professional embedded programming: A Debugger. In order to accomplish effective debugging (i.e. line by line within your source code), you do need a JTAG debugger, and systems such as the jBoard-X2 and the Landtiger board support debugging at a very low cost level.

A CAN Analyzer Is Mandatory

Through the years, I have been contacted by many engineers for advice on their current projects, and mostly the problem was that they were unable to verify the CAN output of their application, meaning they connected to a CAN network and were able to read CAN messages but saw no results when sending messages. Many engineers (and hobbyists) are somewhat blinded by the low cost and ease of programming of systems like the Arduino, Blackberry Pi, and others, but they underestimate the efforts it takes to test and verify the actual application. The first and most important tool for any CAN Bus or SAE J1939 application is a so-called CAN Analyzer or CAN Monitoring software. Such a software tool is the ultimate reference for your application, because you can verify that your application reads and writes CAN data correctly.

I personally use two USB-to-CAN systems that have proven to be reliable and relatively inexpensive (unfortunately, only the sky is the limit), and they both come with a CAN monitoring software:

Connecting to a Vehicle/Automobile Network

Another question that arose multiple times over the years was that about connecting an application to an automobile and scanning for messages. The actual question was in regards to documentation of CAN message IDs. The answer is short and frustrating: There is none. The use of CAN message IDs in an automobile network is highly proprietary. This has nothing to do with being overly secretive (well, maybe to some degree) but mostly with liability issues. Just imagine that, for instance, a company like Porsche uses CAN to control the ABS (yes, they trust CAN that much), and you start interfering with their CAN data traffic...

So, if you have this great idea about a product that uses CAN to manipulate an automobile's data traffic, my advice is: Don't!

The situation is a bit more relaxed when it comes to SAE J1939, where most of the data is standardized and message exchange does not interfere with safety-relevant functionality.

And, of course, you are on the safe side when it comes to using CAN for industrial control applications.

Last, but not least, for more information on the topic see: CAN Bus and SAE J1939 Prototyping with the ARM Cortex M3 processor.

A Comprehensible Guide to Controller Area Network by Wilfried Voss represents the most thoroughly researched and most complete work on CAN available in the marketplace.  Controller Area Network (CAN) is a serial network technology that was originally designed for the automotive industry, especially for European cars, but has also become a popular bus in industrial automation as well as other applications. The CAN bus is primarily used in embedded systems, and as its name implies, is a network technology that provides fast communication among microcontrollers up to real-time requirements, eliminating the need for the much more expensive and complex technology of a Dual-Ported RAM.  This book provides complete information on all CAN features and aspects combined with a high level of readability. => Read more...