Go Down

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


variant.c    CAN Pin Descriptions

-Lines 234 and 235 contain CANRX0 (68) and CANTX0 (69)
-Lines 281 and 282 contain CANRX1 (88) and CANTX1 (89)
-Line 286 contains function call of all pins in CAN0 (90)
-Line 288 contains function call of all pins in CAN1 (91)

variant.h     CAN Pin Definitions
- Line 157 defines CANRX (68)
- Line 158 defines CANTX (69)
- Line 164 defines CAN1RX (88)
- Line 165 defines CAN1TX (89)
- Line 168 defines PINS_CAN0 (90)
- Line 170 defines PINS_CAN1 (91)

There are other descriptions/definitions for the CAN transceiver pins but if your variant files contain the information above, you have the right variant files.

I apparently did not have the right variant files.  I looked on github and just copied and pasted from the CAN branch updated by cmaglie.  Is there other files I should be worried about?  It's still only showing the initial "Type CAN message to send" with no response to what I type and send.



Apr 10, 2013, 08:55 pm Last Edit: Apr 10, 2013, 08:58 pm by Palliser Reason: 1
Hello jspobuk,

Copy the variant files attached below (they are the same files in github CAN branch):

Then paste them to your Arduino files under the 'arduino_due_x' folder:


Let me know.

EDIT: These variant files should replace the current ones in your computer.


A few pictures from today's testing. Seems to be going well so far...

Just need to get a suitable power supply for the arduino plumbed into the car and decide what other features I want to get in.


Hello Sherlock3112.

Thank you for posting pictures of your project! A kind of CAN/XBEE/Ethernet/PC system I assume.
About the PC software, it looks interesting. Formula Student 2013. Could you tell us a bit about your interface .NET?


Yeah, using VB .NET with the NI measurement studio to make the gauges/graphing a bit easier. The ethernet shield is only in there for the SD card slot atm until I get hold of one of the newer wireless shields.


Pallise, AdderD

I see big progress on CAN library, nice work!
I see that there is also some confusion on how to install the library: can I do some "cleaning"
work on the Arduino repository? Do you want me to merge something?

Or maybe its better to remove the CAN library from the main repository, so you can work autonomously?



Hello Cristian,

Above all, thank you very much for your words and interest to consolidate the Arduino Due CAN API library.
So far, I have been testing both sets of CAN files (AdderD's and mine) and since you have asked, I think it is time for an update. AdderD files should replace my files on Arduino github given that his files are compiling/running OK and they are more high leveled, more automotive-oriented and more user friendly, even though few people have been downloading/working with them. I want to mention that some updates need to be done in the new Arduino IDE 1.5.3 (AdderD and me could PM you about it) that will help making easier the installation of the files. Finally I would like to thank AdderD and you for all the time, effort and support here with the CAN library.

What do you think?



Yeah, go ahead and merge my code in. It seems to be working for a number of people. I'll keep at it when I've got time. There's still plenty to do but as it sits it pretty much works.


Apr 21, 2013, 02:32 am Last Edit: Apr 21, 2013, 02:34 am by Graynomad Reason: 1
even though few people have been downloading/working with them

Doesn't mean we're not interested though, the board Rockwallaby an I are designing will have one (maybe two) CAN transceivers as standard equipment.

So we're interested in how this goes, just nowhere near ready to use any code yet.

The reason there may only be one xceiver is that one of the CANRX signals clashes with DAC1 so to have both is a pain.

Rob Gray aka the GRAYnomad www.robgray.com



13 pages on this topic isn't enough :-D

Here is more CAN stuff, as I just discovered this while taking news of OpenXC project: https://github.com/openxc/cantranslator

Maybe this can help you going further.

I don't remember who posted about CanOpenNode project hosted on Sourceforge (http://sourceforge.net/projects/canopennode), but it seems also really interesting for people wanting to move on higher industrial bus (interoperability).


The code within the OpenXC project seems reasonably decent. There might be some potential to use some of it. I think I'm the one who mentioned canopennode before. However, it seems a bit hard to understand. My goal is to end up with a canbus library that has legible source code that people can easily read and/or modify to suit their needs. Canopennode isn't terrible in this regard but it isn't quite up to the level I'd like to get to. Still, it is a good reference for an implementation of canopen.


Apr 23, 2013, 08:10 pm Last Edit: Apr 24, 2013, 02:59 am by zabaat Reason: 1
Thank you all again for your wonderful work - just vouching for the awesomeness of Adder's work

I really liked this sparkfun shield


Maybe a little help here though. I would like to send more than 8 bytes, the following excerpt of code was my best guess but it sits there with a blank stare.

What do I need to change if I want to send this other data?


Code: [Select]
#define TEST1_CAN_COMM_MB_IDX    0
#define TEST0_CAN_TRANSFER_ID    0x07
#define TEST1_CAN_TRANSFER_ID    0x08
#define TEST2_CAN_TRANSFER_ID    0x08
#define TEST3_CAN_TRANSFER_ID    0x09
#define TEST4_CAN_TRANSFER_ID    0x0A
#define TEST1_CAN0_TX_PRIO       15
#define CAN_MSG_DUMMY_DATA       0x55AAAA55

      CAN.init(SystemCoreClock, CAN_BPS_250K);
  // Initialize CAN0 mailbox 0 as transmitter, transmit priority is 15
  CAN.mailbox_set_mode(0, CAN_MB_TX_MODE);
  CAN.mailbox_set_mode(1, CAN_MB_TX_MODE);
  CAN.mailbox_set_mode(2, CAN_MB_TX_MODE);
  CAN.mailbox_set_mode(3, CAN_MB_TX_MODE);
  CAN.mailbox_set_mode(4, CAN_MB_TX_MODE); 
  CAN.mailbox_set_priority(0, TEST1_CAN0_TX_PRIO);
  CAN.mailbox_set_priority(1, TEST1_CAN0_TX_PRIO);
  CAN.mailbox_set_priority(2, TEST1_CAN0_TX_PRIO);
  CAN.mailbox_set_priority(3, TEST1_CAN0_TX_PRIO);
  CAN.mailbox_set_priority(4, TEST1_CAN0_TX_PRIO);
  CAN.mailbox_set_accept_mask(0, 0, false);
  // Prepare transmit ID, data and data length in CAN0 mailbox 0
  CAN.mailbox_set_id(0, TEST0_CAN_TRANSFER_ID, false);
  CAN.mailbox_set_datal(0, CAN_MSG_1);
  CAN.mailbox_set_datah(0, CAN_MSG_2);
  CAN.mailbox_set_datalen(0, MAX_CAN_FRAME_DATA_LEN);

  CAN.mailbox_set_id(1, TEST1_CAN_TRANSFER_ID, false);
  CAN.mailbox_set_datal(1, CAN_MSG_3);
  CAN.mailbox_set_datah(1, CAN_MSG_4);
  CAN.mailbox_set_datalen(1, MAX_CAN_FRAME_DATA_LEN);

  CAN.mailbox_set_id(2, TEST2_CAN_TRANSFER_ID, false);
  CAN.mailbox_set_datal(2, CAN_MSG_5);
  CAN.mailbox_set_datah(2, CAN_MSG_6);
  CAN.mailbox_set_datalen(2, MAX_CAN_FRAME_DATA_LEN);

  CAN.mailbox_set_id(3, TEST3_CAN_TRANSFER_ID, false);
  CAN.mailbox_set_datal(3, CAN_MSG_7);
  CAN.mailbox_set_datah(3, CAN_MSG_8);
  CAN.mailbox_set_datalen(3, MAX_CAN_FRAME_DATA_LEN);

  CAN.mailbox_set_id(4, TEST4_CAN_TRANSFER_ID, false);
  CAN.mailbox_set_datal(4, CAN_MSG_9);
  CAN.mailbox_set_datah(4, CAN_MSG_DUMMY_DATA);
  CAN.mailbox_set_datalen(4, MAX_CAN_FRAME_DATA_LEN);


I'm doing much of the hardware design for the Due board Rockwallaby and I are doing, I'm at the point of choosing CAN transceivers for the board. Some quotes from the previous 13 pages.

SN65HVD233 has the Loopback funktion
SN65HVD234 has the Standby mode and the
SN65HVD235 has the Autobaud option,

I have chosen two SN65HVD234 CAN transceivers for my first shield (I am considering to use 235's later).

even thou I have done successful tests with the TI SN65HVD234 transceivers, we don't know precisely if they are going to be the best and final choice.

I decided to use two SN65HVD235 transceivers in order to compare them with the two SN65HVD234

I just ordered some 233's from TI.

surely want to migrate to 234 to take advantage of the Due libraries for ultra-low current sleep mode.

It seems that either the 233 or 234 are becoming the transceivers of choice. As they are physically compatible with the only difference being the function of pin 5 which can be controlled by the library it may not affect me at this point.

But does anyone have an opinion on the transceiver choice?

Rob Gray aka the GRAYnomad www.robgray.com


I'm doing much of the hardware design for the Due board Rockwallaby and I are doing, I'm at the point of choosing CAN transceivers for the board.

It seems that either the 233 or 234 are becoming the transceivers of choice. As they are physically compatible with the only difference being the function of pin 5 which can be controlled by the library it may not affect me at this point.

But does anyone have an opinion on the transceiver choice?

I used 234 transceivers on my protoboard and also they're being used for another project I'm involved with. But, for the most part it really doesn't matter. The 233 support loopback but you can loopback anyway when you have two transceivers by just connecting them together. I'm not a huge fan of autobaud but maybe it'd be kind of nice if you or whoever us using your Rockwallaby doesn't know the proper baud of the bus. 234 is nice because it allows you to basically disconnect the transceiver from the bus and turn off like it isn't even there at all. It really depends on your requirements. I'd say 234 or 235 would be the best choice but it depends on whether you value the ability to turn off the transceiver more than you value autobaud.

Go Up