Building a CAN API for Arduino DUE

I am starting this post upon recommendation of Massimo Banzi for channeling the efforts in this forum to contribute to complete the building of the CAN communication protocol interface of the Arduino DUE fully suported by Arduino APIs.

Just as most of you in this forum, I am new with Arduino DUE and with some background in integration, programming, electronics, computing, etc... .
For the last three years I have been involved in a couple of projects interfacing CAN protocol between PCs and PLCs through gateways. The processors that handled the CAN code were all the same: ATMEL ARM AT91SAM7X256. In the same way as AT91SAM7X256, Arduino DUE's ATSAM3X8E contains a highly integrated peripheral set for connectivity and communication that includes dual CAN. So, I have planned, between sips of coffee, to to my best building the aforementioned interface.

I will start using the following hardware/software tools:

Arduino DUE
Atmel SAM3X-EK (ATSAM3X-EK)
SAM3X-EK CAN Demo Sources
SAM3X-EK CAN Demo Binaries
SAM3X-EK Demo Release Notes
AT91SAM CAN Bootloader User Notes
AT91SAM7X256_CAN_tes (666.73 kB) Sourcecodes download (if necessary)

Regards!

EDIT [01-08-15]:

Link of latest version of Arduino DUE CAN library and examples:

Electric schematic Arduino Due - OBD 2 connector

Palliser

great job. I can create a repository for that library in our github and give you access.
Would that work for you?

m

Hi Massimo.
Sure thing. Just PM me details. And you are welcome. That's why I love Open Source technology.
Palliser

ciao! scusate ma io e l'inglese...non andiamo proprio d'accordo xD dopo traduco con Google :wink:

...è da tempo che ho in mente di creare un computer di bordo in macchina, ma avendo l'Arduino UNO ho trovato molta confusione su shield che permettevano la connessione al CAN-BUS della macchina...vorrei sapere...dato che nell'Arduino DUE la connessione CAN è gia implementata all'origine...sarà fattibile come progetto??

Grazie a tutti anticipatamente =)

GOOGLE TRADUTTORE xD

hello! sorry but I and English ... we do not go quite agree xD after I translate with Google;)

has long ... I have in mind to create an on-board computer in the car, but having the Arduino UNO I found a lot of confusion shield that allowed the connection to the CAN bus of the car ... I want to know ... since CAN nell'Arduino DUE that the connection is already implemented as a project source ... it will be feasible?

Thank you all in advance =)

The Arduino Due has a can interface. at the moment the software API is not done yet.

Continue the discussion on the Italian forum.

----- Italiano ----

Ciao

L'Arduino Due ha l'interfaccia CAN ma mancano le API software. ci stiamo lavorando sopra.

Ti consiglio di postare la domanda sul forum italiano, questo è in inglese e diventa complesso gestire più lingue contemporaneamente

m

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