Go Down

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


Somebody cann tell me if there is a Way to use the CAN on the DUE?
I must works well and it must work guaranteed. :-)

Would be great if someone with Arduino/CAN/DUE experience can talk to me in a pm. Thx a lot.

Yes, there is a way. You're in the right thread for that. It does work, the library has been used in several projects including an electric vehicle ECU that has sales in excess of 30 at this point (yes, that's still small but large enough that you can be sure we've tested it and there are many other people using it on a regular basis). Will I guarantee it? Of course not. It's software and its free. If it works for you, great! If it kills your cat, runs over your grandma, slaps your wife, and gives you diarrhea then I apologize.

FWIW, I recently posted a link to my version of the library. There is also another version which I believe is a bit more specialized to work in automotive uses. Pick your poison and we'll try to help.

Apr 27, 2014, 05:15 pm Last Edit: Apr 27, 2014, 05:33 pm by ArtificialDemon Reason: 1
Hey guys,

I bought the DUE somewhere in 2013, since it supports CAN. Then I found out it also needed a tranceiver and the libraries were not finished at all.
Therefore I´ve been monitoring this thread for a long time and when the library/libraries finally were kinda finished, I started to gather the stuff I needed to build the hardware.
Firstly, thanks for all the effort! I really appreciate it and without this effort my initial plans would have been destroyed.
In short, I'm connecting a TFT monitor and CAN to the same DUE in order to communicate between my car's ECU and the TFT. No OBD stuff here. I only need CAN for stable communication since I should be able to control the messages sent by the ECU (non OEM, hence no OBD)

Some bumps I encountered is the fact that this thread lacks a bit of overview. It's not immediately clear where to find the circuit that needs to be built and with multiple libraries, several versions etcetera I was not quite sure if I actually have the most recent and best fitting library for my purpose.
Don't take this in a negative way ;) It's just meant as some feedback from a "noob".

Today I built the circuit on my breadboard and used Collin's library and was very surprised to see actually something happening in the serial monitor.

-Example 1 and 2 do show what message has been received, but it does not print which message was sent.
-At example 3 I got weird ASCII symbols in my serial monitor, and a quick search forced me to modify the baud rate to 9600; apparently when this is not the same for the monitor and the arduino, it puts out weird symbols.
Changing the baud rate fixed it.
-Example 4 (ping/pong); also changed the baud rate, but I found out that the communication stops after a few times.
Can't really figure out why this happens. This is the output on my monitor:
Code: [Select]
S: 5002 R: 5001
S: 10004 R: 10003
S: 15006 R: 15005
S: 20008 R: 20007
S: 25010 R: 25009
S: 30012 R: 30011
S: 35014 R: 35013
S: 40016 R: 40015

After that, it just stops communicating. Any ideas?

Transmitting works, so my next challenge is understanding what actually happens. I'm trying to understand everything by the documentation mentioned in this thread, but for now some things are not completely clear.
I probably will ask a lot of dumb questions in the near future, so forgive me for that ;)

Thanks again!

edit: first question already
I've left out the terminator jumpers. I assume these jumpers are necessary to leave out the terminator resistors (120ohm).
Is this correct? When should I make use of this? Is it when I have 3 units on the same network? Only two should be terminated, right? So in my case I would use one terminated arduino channel (CAN0), and terminate at the ECU side. If I would connect another Arduino with CAN, or would also make use of CAN1, I should not terminate this connection with the resistor, is this correct?


It forms a transmission line.

at the ends.
and the can-bus is a twister, pair, which has  a characteristic impedance of 120 ohms
if the line is not terminated ,you get reflections.  (noise)
there is also a split method.
the lines are balanced or they  would never work this fast.
in fact they are called, balanced transmission lines, in electronics.

the DUE has no drivers, you must add the drivers.    the current is very high, way more that a processor can muster.
if you read all posts, you see everyone, making up their own drivers.


the driver can source 50 milliamp min.  nothing trivial that.

togglebit, CAN shield, WIP (to build a jeep CAN monitor)

Apr 27, 2014, 10:13 pm Last Edit: Apr 27, 2014, 11:51 pm by ArtificialDemon Reason: 1

It forms a transmission line.

at the ends.
and the can-bus is a twister, pair, which has  a characteristic impedance of 120 ohms
if the line is not terminated ,you get reflections.  (noise)
there is also a split method.
the lines are balanced or they  would never work this fast.
in fact they are called, balanced transmission lines, in electronics.

the DUE has no drivers, you must add the drivers.    the current is very high, way more that a processor can muster.
if you read all posts, you see everyone, making up their own drivers.


the driver can source 50 milliamp min.  nothing trivial that.

I understand. The functional diagram learns me that in my whole CAN system, I need exactly 2 terminator resistors. No more, no less.
So, to get back at my original question, the jumpers need to be removed if I don't want to terminate at the DUE, but let's say somewhere else.

Your mentioning of "twisted pair" triggers another question.. I was planning to use RJ45 connectors on my application, where normally I see DB9(ish) connections. Any particular reasons not to use RJ45 with regular twisted pair (ethernet) cables?

Somehow the problem with CAN Sample 4 magically solved itself when I restart my monitor.
Thanks for the documents btw!

edit: one of the documents answered my question already.
These include the 9-pin DSUB shown in Figure 11 , Multipole, RJ10, RJ45, M12, the 5-pin mini-style in Figure 12 and more micro-style connectors in the CiA specification document DR 303-1, V1-3

So the RJ45 should work fine.


the jumpers are on pro grade driver boards, like mine, they are PCB layed out nice , with jumpers for term.

the DUE has no CAN drivers. so has no term jumpers, it's just the CAN raw, lines. 3v logic, lines. not CAN drive.
the balanced transmission lines, are all different. (ever work with Computer SCSI HDD systems, they too are balanced and terminated and will fail if done wrong, big time)

it depends on the wire type, and insulation, type. the 120 ohms is just the typical impedance of twisted pair.
and COAX cable ( like my instructor said) is really like infinite turns of twisted pair, see?   think about that, see that?
the equations for  the wires is easy, but id no worry it,   (wire center to center distance being major player)

on my car , im jacking into the radio harness CAN-Bus. (as others, taught me) Google "jeep Can-bus"
I'm attempting to learn all can-codes for all majors, in car. for sure all switches, turned on, etc.
on cars, today, lets say , you turn on the blinkers.?
did the switch fail, or did the can-bus command fail to go out or id it not bet repeated to the lamp controls. or what?
that is my goal is to be able to see all  that., and diagnose that.

good luck with you project,
im very slow do to home projects, to do before air temps hit 100F. 

what TFT did you  use, that is my next step is built in display, I might just use and old VGA screen.(flat)
togglebit, CAN shield, WIP (to build a jeep CAN monitor)

May 11, 2014, 11:26 pm Last Edit: May 11, 2014, 11:37 pm by ArtificialDemon Reason: 1
must keep this thread alive...

I'm running into problems since I don't have any documentation and have to understand the code by reading it. This is not fail safe and takes a lot of time.

My ECU is sending messages over CAN. I'm not sure what they look like, but I see voltages changing compared to when it is not broadcasting CAN messages. What I know is:
- My arduino can talk to itself. As mentioned, the examples worked fine.
- I disconnected CAN0 and connected that side to my ECU. So CAN1 is connected (correctly) to my ECU. I also used a common ground.
- I'm using Sample_1 as base, in which I removed the "sending stuff" from CAN0. In short.. CAN1 mailbox 0 has ID 7 and has a mask of 0x7FF (2047 in dec).

The ECU uses:
- 11 bit header.
- some message ID in the message
- Not sure if it has a specific address in the header, since it is broadcasting.

Should I change anything  to deal with the 11-bit header? I vaguely recall something about a bit in the header which contains information about header length, so it might automatically be resolved?

How does the mask work? Can I configure the code to accept any message? I'm sorry if this has already been answered somewhere...
Will there be some documentation at some point to give additional information on the examples? Like "we set this to xxxx because ..." "change this to xxxxx if you want yyyy"

Everything is going pretty well though... :) haven't wrecked anything yet. I'm looking forward to my euforia when I actually see a reception in my serial monitor  8)

edit: ok I received something :P
I changed the bitrate to 500Mb/sec, on which the ecu apparently sends.
Still confused about message Id's and masks, so please answer those questions if you're able... but at least I got something and I'm really really really happy.


As you found, the first order of business is to set the CANbus speed to the same speed that everything else on the bus was set to. If you don't do this you'll mess up all canbus comms and bad thing might happen. A common side effect is that your dashboard either quits working or goes nuts.

Now, the next issue is canbus mask and filter. You should use the most recent canbus library of mine and find the CAN_TrafficSnooper sketch. It sets the hardware to accept all frames and displays when it sees. This illustrates something about the mask and filter but I'll quickly go over it here.

Let's say a frame with id 0x211 comes in to the Due. The first thing that happens is that the Due hardware takes that ID and does a bitwise AND with the mask. So, let's say you have a receive mailbox with a mask of 0x7F0. 0x211 AND 0x7F0 is 0x210. The next thing is that it compares the new value with the value in the filter. If the filter value is 0x210 then they match and the frame is accepted. It's that simple. This same thing happens for all receive mailboxes. AND with mask, compare to filter. So, if you set your mask and filter to zero then it will always match because anything AND 0 is 0. You can use this capability to filter based on ranges. If you set a mask of 0x7F0 as in my example then it will accept any frame that matches the filter where the bottom nibble is ignored for matching purposes. This is quite common.

But, you're right, some documentation should probably be written.

May 12, 2014, 10:14 pm Last Edit: May 12, 2014, 10:21 pm by ArtificialDemon Reason: 1
Downloaded everything from:

That's the correct version, right?
Thanks for the clear repsonse! I'm getting some data when I set  the mask to 0x5F1, but it appears to read the values from 0x5F3. Perhaps this is due to my misunderstanding of the mask or something.

Can you tell me what the boolan "ext" does in method mailbox_set_accept_mask (edit: I figured it's extended headers..)
I'll try to see what happens when I accept everything. Since my ECU works with offsets from a base identifier, I won't be able to know what it actually means.

Is my assumption correct that I should initialize a mailbox for every "offset"? So the first 8 bytes sent by my ECU should be at the base identifier, these will be dropped in mailbox 0. The next 8 bytes in mailbox 1 etc etc... is that the way I should implement it?

oh boy your traffic  snooper works awesome. This is perfect for debugging and the code is easy to understand. Great job :)

Hey guys,

I only need one CAN channel, and need the pins used for CAN1 for something else. The pins DAC0 and D53 won't be used for CAN.
Do I have to change the header files?

The header in the library used contains the following code:
Code: [Select]
#ifndef PINS_CAN0
static const uint8_t CAN1RX = 88;
static const uint8_t CAN1TX = 89;

// CAN0
#define PINS_CAN0            (90u)
// CAN1
#define PINS_CAN1            (91u)
#define ARDUINO152

This is unclear to me. I know which physical pins are used, but can't figure out how they correspond to the numbers I see.
I use the diagram in the following thread for reference:

88 and 89 are used for CAN1? How do these relate to the diagram in the above thread?

Since I'm using other libraries that use the pins, the pins will be referenced more than once. This will probably cause no problems when the code is not called, but I'd like things to be safe.
So if I won't initialize CAN1, there should be no problem, correct?

Could arduino/compiler notice these 'conflicts' and pose problems?

tl;dr what's the safest way to use one CAN channel and use the pins used for CAN1 for other functionalities.


Hello ArtificialDemon,

You shouldn't have any problem using the CAN1 pins for other purposes ( like read Analog channel 0, etc...).
Notice that the CAN1 pins were added later to the variant files.

Those pin numbers are 'consecutive numbers' of the Due PinDescription. 88 and 89 correspond to the CAN1 port itself. The other numbers (90 and 91) correspond to a COMBO which is an attribute telling the higher level layer that the description is multi-pin oriented. Notice that that was also done for the USART, TWI, SPI, etc.. in order to make easier the init understanding. You will surely see new number in the future every time the Arduino team add new libraries/functionality to Due like for example the EMAC peripheral, etc. Regards,


ArtD- if what you are looking to do is just talk to an ECU with 11 bit ID, you could probably use my free running library that sits on top of collins original code yet below the obd layer, it handles the filter settings for you. Only takes a few lines to implement, I think gone has done some work with it and posted feedback.Let me know if I can help. As for a working hardware I put my schematics up on my page as well...which is really just based upon information posted in this thread. Good luck!
Dan - www.togglebit.net - Arduino DUE proto shields - Arduino DUE CAN shields

Hello everyone, I am new to the Arduino Due . I have brought the CAN transceiver mcp2551. I don't know if I can use the mcp2551 to connect Arduino Due. And can I use the Due_can library code? I see that includes sn65hvd234.h ,therefore I am not sure if it is suitable for the mcp2551.

Thanks in advance.


It actually isn't that good of an idea to try to use the MCP2551. That chip requires 5V while the Due is 3.3V. This difference will make using the chip difficult. You really do want the proper transceiver or another 3.3V compatible transceiver. There are lots of choices out there. The transceiver you use isn't really that important but you do need to match it to the proper voltage level.

thank you ,Collin80 .

It's no wonder  that the Can initial  is completed, but the message can not sent or received. The key problem is the  voltage difference between the transceiver and Due. I will solve it and hope it will work later.


Hello everyone, I am new to the Arduino Due . I have brought the CAN transceiver mcp2551. I don't know if I can use the mcp2551 to

The MCP2562 looks to be a much nicer choice, voltages for IO and CAN are separete so you should be able to plug it into your Due without problems. I'm going to order some for my Due+CAN project.

Go Up

Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

via Egeo 16
Torino, 10131