Go Down

Topic: Building a CAN API for Arduino DUE (Read 454456 times) previous topic - next topic


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



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.



Nov 13, 2012, 11:31 pm Last Edit: Nov 14, 2012, 08:43 am by keija Reason: 1

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

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

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

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:

Code: [Select]

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

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

// Initialize CAN Controllers (defines structure, enable clock)

// 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
  //Reset all CAN0 and CAN1 mailboxes
  //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
  // initialize the digital pin as an output.
  pinMode(led13, OUTPUT);

void loop()
  // Send out information in CAN1 mailbox 8
  Serial.println("Test passed");
  digitalWrite(led13, HIGH);}
  Serial.println("Test ERROR"); 



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  :D



Nov 18, 2012, 12:59 am Last Edit: Nov 18, 2012, 01:04 am by keija Reason: 1
"No CAN due-sville, babydol" ?

Wow Palliser - you seem to be really focused on this :O thanks for spearheading!


I haven't heard of CAN protocol until reading this thread, so I am wondering (just in case I'm missing out on learning some interesting things):
What is "CAN protocol" used for? Automotive applications were mentioned (so I assume car odometer, engine status, etc.), but what other applications can it be or is commonly used for?


Nov 18, 2012, 07:14 am Last Edit: Nov 18, 2012, 07:16 am by Palliser Reason: 1
Hello giantsfan3. In my case, I started getting interested in the CAN protocol after been involved for over a year integrating a German Battery Manager System (CAN) with a PLC (Modbus RTU). Then, I understood why CAN is one of the most reliable communication protocols I ever seen. In the particular case of the microcontroller inside of the Arduino Due (SAM3X8E), there are about one hundred configurable registers! (status, interruptions, errors, etc.). The CAN protocol has been around for more than 25 years. Just two wires, it offers high-speed communication rate up to 1 Mbits/sec thus allows real-time control. CAN can theoretically link up to 2032 devices (assuming one node with one identifier), excellent error handling and fine fault confinement. Used to operate in robust, electromechanical (noisy) environments like in automotive, also in medical apparatus, textile machines, elevators, agricultural and nautical machinery. There are other CAN-based higher layer protocols like CAN Application Layer (CAL), CAN Kingdom, CANopen and DeviceNet.

Just Google it or Wikipedia. You can check the following compendium of the CAN protocol and uses in the automation industry.

We hope soon, see Arduino Due fans contributing with new cool CAN applications. Regards.


Nov 25, 2012, 03:16 pm Last Edit: Jan 30, 2013, 09:33 pm by Palliser Reason: 1
Implementing the CAN physical layer.  

For the implementation of the physical layer of the Arduino Due CAN interface, we need a mean to translate the CAN messages to/from differential signals across a physical medium such as a twisted pair cable.

CAN transceivers provide that differential physical layer interface between the data link layer (CAN controller inside the SAM3X8E) and the physical wiring of the CAN bus.

CAN has only two bus voltage states; recessive (driver outputs are high impedance) and dominant (one bus line, CANH, is high and the other, CANL, is low), unlike the traditional differential data transmission where a logic 1 is transmitted as a voltage level high on one noninverting transmission line and low on the inverting line. Correspondingly, Logic 0 is transmitted as low on the noninverting line and high on the inverting line.

For obvious space reasons, we need a shield to mount the transceivers, some pull resistors, capacitors and the CANL CANH connectors.

I have chosen two SN65HVD234 CAN transceivers for my first shield (I am considering to use 235's later). Because I am prototyping, for the board I will use a SchmartBoard (RadioShack 2760259). The shield will provide 2 can ports (CAN0 and CAN1).

Here a picture of the transceivers circuit. It's very simple, just a  straight connection with the arduino CAN ports. Later on, I have planned to use some features of these transceivers like high-speed and low power modes that will required 4 more Arduino Due pins (2 EN and 2 RS).

Regarding the code, I already have my Arduino Due talking CAN 2.0A but a library optimization is required before upload the files in github. Thank you again for your patience and keep looking out my post.


"Long-time listener/first-time caller" here...  I just wanted to point out an interesting discussion regarding use of an Arduino-compatible 32-Bit board (the ChipKIT) and a CAN Communication Interface for the Ford Motor Company called OpenXC (http://openxcplatform.com/).  The discussion forum can be found at https://groups.google.com/forum/?hl=en&fromgroups#!forum/openxc
  I have no idea if there's any way these two efforts can be of use to each other, but I figured I'd mention it...
Keep up the exciting work!

Go Up