Building a CAN communication protocol interface for Arduino Due (Scope)
Arduino introduces the Due board as a heavyweight bridge between mature Arduino tinkerers and advanced new cool open source applications to come. Focused more on expanding its elderly relative’s platform’s features and also focused in the outer world, Arduino Due with its 84 MHz clock, 512 KB of flash memory, 12 analog inputs (ADC), high-resolution analog outputs (DAC), 4 UARTs among other new features, it is capable of host our USB devices like mobile phones, cameras, printers, playback our wav and ogg music, and very soon…interact with our vehicles. And it is with this latter universe, that Arduino Due will make easier for us to materialize custom ideas using the communication Controller Area Network (CAN) protocol which rests inside, not only the most of modern vehicles, but everywhere.
This tutorial-post will take us to develop the working source code for the CAN protocol interface of Arduino Due supported by the Arduino API.
With your help and the help of Atmel and the Arduino team, I have planned to create a software foundation for the CAN platform using Arduino and Atmel development tools to design the C++ project to communicate with different intelligent CAN devices. This is made possible thanks to the dual CAN processors inside the Arduino Due platform based on Atmel ARM SAM3X processor.
I will start running and debugging sample CAN codes provided by Atmel that send/receive messages over CAN bus. In the meantime, we will use easy-to-read schematics and illustrations to explain in the most simple way, the structure of the CAN protocol and its several parts like configuration registers, message objects (mailboxes), etc.
Something very important: All the software we will be using is open and free to download (some free registrations may apply).
The CAN specification to be implemented in Arduino Due is defined by ISO/11898A (2.0 Part A and 2.0 Part B) standards for high speeds and ISO/11519-2 for low speeds.
Now, before start our first line of code, let's talk a bit about the Controller Area Network and a short walk through the history behind it.
“Controller Area Network (CAN) is a network protocol that allows multiple processors in a system to communicate efficiently with each other. In the early 1980s microprocessors became small enough and powerful enough to start appearing everywhere, not just inside personal computers. The typical automobile built since 1985 has dozens of embedded processors. Electronic fuel injection systems have replaced carburetors. Anti-lock braking systems use fast microprocessors to make split second decisions, as do safety systems like air bags and seat belts. Other systems have built-in processors to work as sensors, keeping track of and reporting on temperature and pressure changes for the coolant system, transmission, and oil. Still others monitor emissions, steering performance, and brake fluid levels. As more and more electronic systems were added to automobiles and other machines to make them safer, more efficient, more reliable, and easier to maintain, it became increasingly important for these systems to communicate with each other. To this end the Controller Area Network protocol was introduced in 1983. Today Controller Area Network is the standard for high-speed, mission critical, real-time control networks in many machines. CAN chips are reliable, simple, and cheap. They last a long time and are able to endure temperature and pressure extremes”.[1] www.parallax.com/dl/docs/prod/comm/cantechovew.pdf
“Today, electronic components and systems account for over 20% of the cost of a high end passenger car. In-vehicle networks are already successfully applied to body and powertrain control systems. This figure is expected to grow significantly over the next ten years with the introduction increasingly more complex control systems such as Drive-by-Wire and multimedia systems giving access to the internet”.[2] www.atmel.com/Images/doc7548.pdf
“In February 1986 at SAE Conference in Detroit, Controller Area Network (CAN) was officially introduced by Robert Bosch GmbH in anticipation of future advances in onboard electronics”.[3] How to Diagnose a CAN Network
“It was called the "Automotive Serial Controller Area Network” because CAN systems were
developed first for the automotive industry. It quickly became obvious, however, that the protocol would work extremely well in a wide variety of embedded systems applications. In 1990 CAN technology was introduced for weaving machines, and today the textile industry makes heavy use of CAN systems. CAN chips are found in elevator systems in large buildings, ships of all kinds, trains, and aircraft, in X-Ray machines and other medical equipment, logging equipment, tractors and combines, coffee makers, and major appliances. Today almost every
new car built in Europe has at least one CAN system, and CAN has become the industry standard for communications systems in vehicles. Industry leaders expect steady growth in CAN systems for all types of machines and equipment.” [4] www.automationmag.com/.../network-evolution-25-years-of-connect...
Let me now turn to the two CAN Controllers contained in the SAM3X8E. Each CAN (Controller Area Network) is a stand-alone controller for the Controller Area Network widely used in automotive and industrial applications. Core has simple CPU interface (8/16/32 bit configurable data width) with little or big endian addressing scheme. CAN support both standard (11 bit identifier) and extended (29 bit identifier) frames. Hardware message filtering and 64 byte receive FIFO enables back-to-back message reception with minimum CPU load. This two CAN Controllers are able to handle all types of frames (Data, Remote, Error and Overload) and achieves a bit rate of 1 Mbit/sec. As regards CAN protocol, Arduino Due contain just two pins: CANTX and CANRX equivalent to the CAN_H and CAN_L known twisted wires.
Now, turning to substance, I have planned to implement three feasible approaches to build the CAN interface supported by the Arduino API. The first one is based on using the Atmel development kit board SAM3X-EK ($180) with Atmel SAM-BA software and a debugger like J-Link or SAM-ICE. Once defined and tested the sample CAN project, we will move to the second approach using Atmel Studio 6 (powered by Visual Studio) with Atmel Software Framework (ASF). Finally, having a proven CAN code, we will create the Arduino Due sketches in Atmel Studio 6.
So our first step will be with to port a very simple CAN example project for the SAM3X-EK board. I will test the original sample project connecting in loop the two CAN ports available in the SAM3X-EK board. Then, I will remove the ‘jumper’ between CAN ports and connect one of them with a real CAN device. As this project progresses we can find anything on the way. I mean, errors, bugs or something worst: nothing. And it is then that your full participation will take place. Anyone is free to participate with ideas and questions. Like the most of you, I have my work and set aside time to do this for free. Why? Because I love open source!
First approach:
To run the sample CAN project using the SAM3X-EK board, it will be required to load the CAN_CAN_Example1. Please, refer to the following replays on this post for further details.
Once this test is successfully finished, I will upload all the files in a dedicated repository in github.
Second approach:
We not only will run the same CAN_CAN_Example1 project using Atmel Studio 6 but also customized that sample to communicate with a real CAN device. For this, will be required to add some services/drivers/components from the ASF using ASF Wizard (By cross checking with the existing CAN_CAN_Example1 project for SAM3X-EK). Another changes will be necessary in the conf_uart_serial.h file (UART interface settings) and arduino_Due_x.h file (adding define CAN pins) before compile the project.
Similarly, once this test is successfully finished, I will upload all the files in a dedicated repository in github.
I have decided to explain in more detail the third approach a little later. As I quoted at the beginning of this scope, we will create the Arduino Due sketches in Atmel Studio 6.
In my next reply, I will present the hardware/software tools to be used to start with the first approach. regards!