Building a CAN API for Arduino DUE

system · April 10, 2013, 6:26pm

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.
[/quote]

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.

Thanks

Palliser · April 10, 2013, 6:55pm

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:

...\arduino-1.5.2-windows\arduino-1.5.2\hardware\arduino\sam\variants\arduino_due_x\

Let me know.

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

variant.cpp (22 KB)

variant.h (5.77 KB)

system · April 13, 2013, 1:33am

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.

Palliser · April 13, 2013, 4:41pm

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?

system · April 13, 2013, 4:44pm

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.

cmaglie · April 19, 2013, 8:08am

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?

Palliser · April 20, 2013, 4:22pm

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.

AdderD,
What do you think?

Regards!

AdderD · April 20, 2013, 6:32pm

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.

graynomad · April 21, 2013, 12:32am

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

aethaniel · April 23, 2013, 2:19pm

Hello,

13 pages on this topic isn't enough

Here is more CAN stuff, as I just discovered this while taking news of OpenXC project: GitHub - openxc/vi-firmware: OpenXC-compatible firmware for PIC32 and LPC1768

Maybe this can help you going further.

I don't remember who posted about CanOpenNode project hosted on Sourceforge (CANopenNode download | SourceForge.net), but it seems also really interesting for people wanting to move on higher industrial bus (interoperability).

AdderD · April 23, 2013, 3:34pm

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.

system · April 23, 2013, 6:10pm

Thank you all again for your wonderful work - just vouching for the awesomeness of Adder's work

I really liked this sparkfun shield

system · April 24, 2013, 8:57am

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?

Thanks!

#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);
  CAN.reset_all_mailbox();
  // Initialize CAN0 mailbox 0 as transmitter, transmit priority is 15
  CAN.mailbox_init(0);
  CAN.mailbox_init(1);
  CAN.mailbox_init(2);  
  CAN.mailbox_init(3);
  CAN.mailbox_init(4);  
  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);

graynomad · April 24, 2013, 10:08am

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

AdderD · April 24, 2013, 1:29pm

Graynomad:
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.

AdderD · April 24, 2013, 1:41pm

zabaat:
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?

Thanks!

It seems to me that the only thing you're really lacking is that you forgot to pull the trigger at the end. You have to tell it to send those mailboxes once you load them. You can do this one at a time, stagger them, or however you wish. If you want to try to tell it to send all of the mailboxes as fast as it can then do this:

  CAN.global_send_transfer_cmd(CAN_TCR_MB0 | CAN_TCR_MB1 | CAN_TCR_MB2 | CAN_TCR_MB3 | CAN_TCR_MB4);  //send frame in mailbox 0-4

I should probably abstract that a bit. It looks kind of ugly as-is.

Edit: BTW... I just changed my displayed user name, still the same person, different ID. This matches my github account (where the due_can library is hosted.)

Markus_L811 · April 24, 2013, 1:42pm

Quote my self...

Markus_L811:
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.

I did not know if the functions allready implemented in the library, but compared to the functions of the SAM and the TI Transciever I would choose the the SN65HVD233 to make it complete without having some option 2 times

graynomad · April 24, 2013, 3:27pm

I think the Atmel designers have made the choice for me. I was leaning towards the 234 anyway because of the EN function that allows me to save power, then I remembered that CANRX1 shares a pin with DAC0 so it's important to be able to tri-state CANRX1 if you are using the DAC.

So it's the 234 for me, no choice unless I add a FET switch or something.

If the library doesn't support controlling the EN pin (it should, we all want to save power :)) then I'll cross that bridge when I come to it.

Rob

AdderD · April 24, 2013, 4:24pm

Graynomad:
If the library doesn't support controlling the EN pin (it should, we all want to save power :)) then I'll cross that bridge when I come to it.

It does use the enable pin. But, right now as soon as CAN and CAN2 are instantiated they immediately enable the transceiver and leave it enabled. So, the library basically assumes you're using a 234 chip. This has been accurate for the most part. Since they're instantiated automatically for you this means that the current library forces the relevant pins to be CAN and enables the transceiver forever. Of course, not everyone wants this behavior so in the future it should be possible to turn off the canbus hardware if required. This is not hard to do at all. I think that the default behavior of automatically turning everything on is still the way to go. If you don't want that you can not include the library in which case it won't do that. But, yes, on the to-do list is being able to disable and re-enable the hardware.

Palliser · April 24, 2013, 9:39pm

In the github CAN samples 1 & 2, I used four pins to control the two transceivers as follows:

CAN0 Transceiver

pin A7 (D61) to enable/disable the lowpower mode.
pin A8 (D62) to enable/disable the transceiver.

CAN1 Transceiver

pin A9 (D63) to enable/disable the lowpower mode.
pin A10 (D64) to enable/disable the transceiver.

But you can choose the pins that best suits your needs. For example, let's say you want to use pin 46 (D46) to enable the lowpower mode in the CAN1 transceiver, you have to use the following code:

SN65HVD234_SetRs(&can1_transceiver, 46);
SN65HVD234_EnableLowPower(&can1_transceiver);

Or, if you want to use pin A4 (D58) to restore normal lowpower mode (disable) in the CAN0 transceiver, you have to use the following code:

SN65HVD234_SetRs(&can0_transceiver, 58);
SN65HVD234_DisableLowPower(&can0_transceiver);

Similar case to enable or disable the transceivers. For example, you want to use pin 14 (D14) to disable the CAN0 transceiver, you have to use the following code:

SN65HVD234_SetEN(&can0_transceiver, 14);
SN65HVD234_Disable(&can0_transceiver);

I hope that the foregoing clarify a bit more the use of the control pins for the CAN transceivers.

EDIT: Of course, the four pins you choose and add to your sketch shall be connected to the transceivers pins EN ans Rs accordingly.

Topic		Replies	Views
Yet another CAN library for J1939, CANopen and CAN support Networking, Protocols, and Devices	21	28610	May 6, 2021
Libreria CAN (Controller Area Network) para Arduino Due Software	3	4673	May 7, 2021
CAN Bus Messages Networking, Protocols, and Devices	51	13229	May 6, 2021
Arduino Due CAN API ? Due	11	8354	May 6, 2021
problem with communication can bus - problema con la comunicazione can bus Due	13	3275	May 6, 2021

Building a CAN API for Arduino DUE

Related topics