Building a CAN API for Arduino DUE

Dear Palliser,

I am extremely, extremely enthusiastic about your building a CAN-bus interface. I do have two suggestions that you might want to keep in mind while you are doing this:

(1) The most common use of CAN by Arduino-community members has been for reading on-board automotive systems, so the header files for libraries I've seen define those messages. OBDC is only one use for CAN, and to my mind the least interesting use for those who want to do something new. I think that it would be very useful for many, and certainly for me, if your interface provided a "friendly" implementation of CANopen. (My particular interest in this is that recent Roboteq motor controllers are CAN capable and aside from raw CAN and a mini CAN subset, they implement CANopen (though only with 11 bit ids).

(2) The Due has two CAN controllers in its processor, but it still needs external transceivers. The ATmega Arduinos need both external controllers and transceivers, but aside from the need to use SPI the CAN protocol is the same. Perhaps your interface could be written so that it would work for both. For example, I've just started working on a simple Arduino NANO CAN shield that mounts only a MCP 2515 and 2551 to use in several embedded CAN nodes. Your interface will surely be much, much better than anything I will come up by hardcoding the frames I need into a modified version of an existing library.

Grazie,
Lenni

Hello Lenni. Thank you very much for your encouraging words concerning this initiative to complete the newly created avenue to make Arduino Due to get seriously involved with the CAN standard.

In reference to your first suggestion, as too many of us know, CANopen is a higher level CAN bus protocol. Even thou both use the CAN 2.0B standard for the physical and data link layer, that's it. They differ from the other five layers in the OSI model. I am completely agree with you about implementing CANopen but we are in the incipient phase in building this interface, so, one step at a time. I believe the help from people like you will be needed very soon. I have planned to take advantage of what is inside the ATSAM3X8E, two can controllers that provide all the features required to implement the serial communication protocol CAN as referred by ISO/11898A that includes 1.0 Part A and 2.0 Part B.

In reference to your second suggestion, yes, it will be necessary a couple of transceiver like SN65HVD234 to provide the required transmission capabilities between the differential CAN bus and the CAN controller. I am taking notes of your comments and other comments from this community to keep in mind. Thank you again.

Palliser:
Hello Lenni. Thank you very much for your encouraging words concerning this initiative to complete the newly created avenue to make Arduino Due to get seriously involved with the CAN standard.

In reference to your first suggestion, as too many of us know, CANopen is a higher level CAN bus protocol. Even thou both use the CAN 2.0B standard for the physical and data link layer, that's it. They differ from the other five layers in the OSI model. I am completely agree with you about implementing CANopen but we are in the incipient phase in building this interface, so, one step at a time. I believe the help from people like you will be needed very soon. I have planned to take advantage of what is inside the ATSAM3X8E, two can controllers that provide all the features required to implement the serial communication protocol CAN as referred by ISO/11898A that includes 1.0 Part A and 2.0 Part B.

In reference to your second suggestion, yes, it will be necessary a couple of transceiver like SN65HVD234 to provide the required transmission capabilities between the differential CAN bus and the CAN controller. I am taking notes of your comments and other comments from this community to keep in mind. Thank you again.

I have interrests to, I would prefer the SN65HVD235 with the possibility off using the Autobaudfunktion without making trouble on the bus. The firm I worked for parttime has many CAN-Bus equipment so I can test.

Implementation of LIN and CAN Arduino Style for the Due is on my ToDo list to get "warm" with the Due.

Hello Markus,

I feel happier today because more people want to get involve with me in this journey. I just mentioned the SN65HVD234 as a known option, but agree with you about the autobaud loop-back and standby mode capabilities of the 235. I have also worked with SN55HVD251 and SN65HVD251, but at the end, its about a community-consensus with the permission of Arduino. So, I encourage you to move to the top of your ToDo list to find the best CAN transceiver option for the transmission between the Arduino Due processor (ATSAM3X8E) and the outer CAN world. Please, keep us posted about your tests and progress. Thank you.

I hope this will be helpful, it is a thread at LeafLabs about getting CAN to work with STM chips.

http://forums.leaflabs.com/topic.php?id=802

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!

This is very exciting, I'm still learning about CAN and have just barely gotten my feet wet so I'm not sure how much I can contribute but I'm available.

Hi Palliser,

I'm very interested in your efforts of getting a CAN-Library working on the DUE.
I have been doing a few things with the CAN-Shield and an Arduino UNO and I know a lot about the CAN-Bus, so I will try to help you getting it done! Sad thing is: I currently have other urgent projects/assignments that i need to address first! (And i need to get a DUE as well :wink: )

I'm looking forward to your CAN-Bus library and I'll try to get involved, as soon as i have the time.
... Sam

Palliser

thanks for the exhaustive introduction. I would keep ASF out of this project, no need to add a million lines of code to access the CAN peripheral. We can extract the info from the relevant files.

Please leave Atmel studio 6 out of the development process, making the code available through the IDE is what we need in order to get many people to help out, test and use the code.

Let me know if we need to design a can shield.

keija: the library will be developed and made available here https://github.com/arduino-libraries/arduino-due-can join github if you want to be part.

m

Hello Massimo,

you talk about the ASF, yes the CAN_CAN_EXAMPLE1 is heavy but all what's needed is there all files maybe some more than needed but the component_"what ever".h are from the AFS or not?

About the files where are the comments?

An Shield is absolutely nessesary an transciever chip is needed to get access to the CAN-Bus.

Markus

Palliser:
Hello Markus,

I feel happier today because more people want to get involve with me in this journey. I just mentioned the SN65HVD234 as a known option, but agree with you about the autobaud loop-back and standby mode capabilities of the 235. I have also worked with SN55HVD251 and SN65HVD251, but at the end, its about a community-consensus with the permission of Arduino. So, I encourage you to move to the top of your ToDo list to find the best CAN transceiver option for the transmission between the Arduino Due processor (ATSAM3X8E) and the outer CAN world. Please, keep us posted about your tests and progress. Thank you.

Uhh Palliser you trapped in the same hole I was, the Series SN65HVD23x are in some way special.

SN65HVD233 has the Loopback funktion

SN65HVD234 has the Standby mode and the

SN65HVD235 has the Autobaud option,

you need to choose the Chipfunction you want, but the SAM supports Autobaud and Sleepmode only the Loopback funktion is missing.

hello Markus,
Let's go by parts:

About the CAN_CAN_EXAMPLE1, I would say don't worry.It is a generic CAN example project for SAM3X-EK board. This same sample was included with the latest ASF of Atmel Studio 6 and in the ASF standalone zip package (GCC & IAR). I decided to use it because I already have the kit board.

As I stated in my scope:

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).

I said some because that's what we need, just few libraries like can.h stdio.h, sysclk.h etc.These libraries were built by Atmel for the SAM3X platform, not for AS6.

About the github files, I haven't uploaded anything yet. I still running tests. And I agreed like the shield. Necessarily, a shield containing (among other things) similar transceivers should be considered for the Arduino Due. Which ones? I don't know yet but we'll find out soon. regards.

By bringing in the ASF you end up duplicating a lot of the functionality already present in the Arduino API.
in the end you need only 4 files plus the example. replace the missing function with the corresponding arduino API and you're all set

m

I think its important that the Library be made so it can run as a background task in a scheduler.
Also that the auto transmit messaging be selected to be optional as sometimes you don't want it to keep transmitting.

K

Hi,

i agree with the notion of making it work within the Arduino IDE without needing too many additional libraries.
I've been using the sparkfun shield and the accompanying library, and it provides the basic functionality of sending and receiving a CAN-Message. It gives you the message-ID and the data Bytes of a received message and requires the same for sending one. Additionally you can set the ID-Filters (although this isn't very intuitive ... and should definitely be improved, as it's the best way to take load off an Arduino UNO :wink: )

I think this should be the basic foundation of the DUE-CAN library. Any additional features can be built on top of that in additional library files/layers, but should be modular (imho).

That would be great! I don't know if its possible with the current pinout, but if you could implement a shield with two CAN-controllers, to interface with two independent CAN-Busses or to act as a gateway, it would be fantastic!

I'm excited about this development and I can't wait to see the first implementations!
... Sam

Thank you again keija for you willingness to help with this CAN interface for the Arduino Due. Remember that the ARM Cortex M3 is different from the 8-bit/16-bit RISC architecture we are accustomed from Atmel and it confines any Due development to it. Right now I am finishing some CAN sample tests and minimizing/trimming all non-necesary drivers/services/components to make this project easier. Regards.

Ok. Change of plans. Henceforth I will stay working with the CAN code available through the Arduino IDE. At the end, a CAN library and a couple of sample sketches will be added to the Arduino IDE as tools to send and receive standard (ver.2.0A - 11 bit) and extended (ver.2.0B - 29 bits) messages, but before this, as I stated in previous posts, I have been running some tests of the sample CAN code provided by Atmel in AS6, SAM_BA 2.12 and my SAM3X-EK board. The purpose of these tests is to dissect and obtain a proven minimum CAN code for the SAM3X8E. Finally, once the necessary source code has been chosen (libraries, .h, .c), we will proceed to program the SAM3X8E in Arduino due through the Arduino IDE.

I know the majority of the CAN protocol fans in this forum look forward to have access to the code but for the moment let me show you a picture my SAM3X-EK and a CAN device (sorry for the wiring mess) and also a pseudo-code and an idealized sketch.

For understand a bit better the following pseudo –code, it is healthy to explain briefly about the CAN platform embedded inside the SAM3X8E core.
The SAM3X8H has two CAN Controllers. We will call these controllers CAN0 and CAN1. The SAM3X8H read/writes from/to them through the PIO A and PIO B respectively. Each of these controllers connects one respective bus. Each bus should comprehends only two transmission lines (CANTX/CANRX) but due to the energy efficiency design of the SAM3X8E, it is required the use of two CAN transceivers (one per bus) between the SAM3X8E and the outer world. Also, we will discuss latter about these transceiver and the future shield.
Here the pseudo-code:
Initialization code (setup)

  1. Define CAN0 and CAN1 transfer mailbox structure
  2. Enable the module clock for CAN0 and CAN1
  3. Initialize CAN0 and CAN1, baud rate (baud/s)
  4. Reset all CAN0 and CAN1 mailboxes
  5. Initialize CAN1 mailbox 0 as receiver, frame ID
  6. Initialize CAN0 mailbox 0 as transmitter, frame ID
  7. Prepare transmit ID, data and data length in CAN0 mailbox 0

Main code (loop)

  1. Send out data in CAN0 mailbox 0
  2. Wait for CAN1 mailbox 0 to receive the data
  3. Read the received data from CAN1 mailbox 0

For a user-friendly interface, I will encapsulate the initialization code in a couple of steps that only include baud rate, frame ID, priority, type of message frame (2.0A or 2.0B) and mailbox configuration(transmitter/receiver).

The main code will use the following functions: send, wait and read.
An idelized Arduino Due CAN sketch will look like:

// Idealized CAN sketch for Arduino Due board
// By Palliser 2012


// Required CAN library
#include <can.h>

// Initialize CAN Controllers (defines structure, enable clock)
CANInit CAN0;
CANInit CAN1;

// Mailboxes frame ID 7 and 8
int MB_ID7 = 7;
int MB_ID8 = 8;

// CAN message to turn on Arduino Due pin 13
int CAN_MSG_HIGH_PIN_13 = 0x11223344
// Arduino Due pin 13
int led13 = 13;

void setup()
{
  //CAN baud rate 1Mb/s
  Can.begin(1000000);
  //Reset all CAN0 and CAN1 mailboxes
  Can.MBReset(CAN0);
  Can.MBReset(CAN1);
  //Init CAN0 mailbox 7 as receiver
  Mailbox.mode(CAN0, MB_ID7, RX_Mode);
  // Init CAN1 mailbox 8 as transmitter
  Mailbox.mode(CAN1, MB_ID8, TX_Mode);
  // Prepare transmit information into CAN1 mailbox 8
  CAN_MB_WRITE(CAN1, MB_ID8, CAN_MSG_HIGH_PIN_13);
  // initialize the digital pin as an output.
  pinMode(led13, OUTPUT);
}

void loop()
{
  
  // Send out information in CAN1 mailbox 8
  CAN_MB_SEND(CAN1, MB_ID8);
  
  while(!recv_status){
  }
  if(CAN0_MB_DATA == CAN_MSG_HIGH_PIN_13){
  Serial.println("Test passed");
  digitalWrite(led13, HIGH);}
  else{
  Serial.println("Test ERROR");  
  }
}

Regards.

I like the wiring, sounds good looking forward to it

I'm almost done with my minimize raw CAN 2.0A (11 bit) running in the Arduino Due with a sample sketch. I'm expecting to receive the transceivers in a couple of days (TI SN65HVD234 & SN65HVD235) and build a shield. In the meantime I've hooked CANRX0<->CANRX1 and CANTX0<->CANTX1 for looping tests. I hope by mid-next week to upload in github the raw CAN code for revision and comments. Thank you for your patience.

I think this should be the basic foundation of the DUE-CAN library.

Oh please, don't miss the opportunity of calling it the CAN-DUE library, we need more nerd humour around here. LOL :smiley:

Lefty