Go Down

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

Collin80

#195
Apr 24, 2013, 03:41 pm Last Edit: Apr 24, 2013, 03:51 pm by Collin80 Reason: 1

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:

Code: [Select]

 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

Quote my self...


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

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
Rob Gray aka the GRAYnomad www.robgray.com

Collin80


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

#199
Apr 24, 2013, 11:39 pm Last Edit: Apr 24, 2013, 11:45 pm by Palliser Reason: 1
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:

Code: [Select]
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:

Code: [Select]
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:

Code: [Select]
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.

Graynomad

Sounds like it's covered. You didn't use a resistor on RS in the post #33 schems, I think I'll add one, value TBD.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Palliser


Sounds like it's covered. You didn't use a resistor on RS in the post #33 schems, I think I'll add one, value TBD.

______
Rob


Hello Rob,

At this time, this is a very good point. Thanks for mention it because it allows me to clarify something:

Knowing that the most important thing in the first stages of this project was to establish a good communication between nodes, I forced a 'direct mode' in the transceivers connecting pins 5(EN) to 3V3 and pins 8(Rs) to GND but now that some users out there have achieved this, their next step should be to deal with the connection/control of those pins if they are interested to exploit the low power mode an other features of these transceivers, thus, a 10K pullup resistor must be connected on EN and a 10K pulldown resistor on Rs according to Atmel's original design (doc11156).

zabaat


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:

Code: [Select]

 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.



I made the change - here is my code again. I still am only getting out on the first TEST1_CAN_TRANSFER_ID :(

Thank you!

Quote

#include <Wire.h>
#include "variant.h"
#include <due_can.h>

#define TEST1_CAN_COMM_MB_IDX    0
#define TEST1_CAN_TRANSFER_ID    0x07
#define TEST2_CAN_TRANSFER_ID    0x08
#define TEST3_CAN_TRANSFER_ID    0x08
#define TEST4_CAN_TRANSFER_ID    0x09
#define TEST5_CAN_TRANSFER_ID    0x0A
#define TEST1_CAN0_TX_PRIO       15
#define CAN_MSG_DUMMY_DATA       0x55AAAA55

// CAN frame max data length
#define MAX_CAN_FRAME_DATA_LEN   8

// Message variable to be send
uint32_t CAN_MSG_1 = 0;
uint32_t CAN_MSG_2 = 0;
uint32_t CAN_MSG_3 = 0;
uint32_t CAN_MSG_4 = 0;
uint32_t CAN_MSG_5 = 0;
uint32_t CAN_MSG_6 = 0;
uint32_t CAN_MSG_7 = 0;
uint32_t CAN_MSG_8 = 0;
uint32_t CAN_MSG_9 = 0;
uint32_t CAN_MSG_10 = 0;
uint32_t CAN_MSG_11 = 0;
uint32_t CAN_MSG_12 = 0;

  // Initialize CAN1 mailbox 0 as receiver, frame ID is 0x07
  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, TEST1_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, TEST2_CAN_TRANSFER_ID, false);
  CAN.mailbox_set_datal(1, CAN_MSG_3);
  CAN.mailbox_set_datah(1, CAN_MSG_DUMMY_DATA);
  CAN.mailbox_set_datalen(1, MAX_CAN_FRAME_DATA_LEN);

  CAN.mailbox_set_id(2, TEST3_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, TEST4_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, TEST5_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);



  // Send out the information in the mailbox
  CAN.global_send_transfer_cmd(CAN_TCR_MB0);
  CAN.global_send_transfer_cmd(CAN_TCR_MB1);
  CAN.global_send_transfer_cmd(CAN_TCR_MB2);
  CAN.global_send_transfer_cmd(CAN_TCR_MB3);
  CAN.global_send_transfer_cmd(CAN_TCR_MB4); 

  CAN.disable();


Collin80



I made the change - here is my code again. I still am only getting out on the first TEST1_CAN_TRANSFER_ID :(

Thank you!

Quote

  // Send out the information in the mailbox
  CAN.global_send_transfer_cmd(CAN_TCR_MB0);
  CAN.global_send_transfer_cmd(CAN_TCR_MB1);
  CAN.global_send_transfer_cmd(CAN_TCR_MB2);
  CAN.global_send_transfer_cmd(CAN_TCR_MB3);
  CAN.global_send_transfer_cmd(CAN_TCR_MB4); 

  CAN.disable();




Why are you disabling the canbus device as soon as you try to send? Those sending commands are just flags that tell the canbus hardware to send out that mailbox when it gets a chance. Likely what is happening is that you send the commands, the bus is free so it starts sending the first frame. Then you disable the hardware so the other four never get a chance to go out. You've got to give it some time to send the frames before you disable the canbus hardware. Figure that a frame could be about 118 bits and then use your baud rate to see how long the minimum time to wait is. At 250k baud this is about .5ms per frame.

cmaglie


I've updated the Arduino "can" branch with https://github.com/collin80/due_can
PM me if there are other changes needed.
C.

dan@togglebit.net

#205
Apr 29, 2013, 04:48 pm Last Edit: May 03, 2013, 02:55 am by tbit Reason: 1
Got my prototype pcb's in and built one up.....seems to have passed ping-pong and skew testing (thanks for writing those tests btw) although i was using a short piece of cable and doing nothing else on the board. I used 233's with jumpers for 120ohm terminations, RS pin (10k on board), and loopback. I like the 233's w/loopback an example use would be if you are doing a project in which you have 2 CAN ports operating at two different baud rates, loopback lets you do some code testing...just my preference. Looking to do some OBD testing next, Feedback appreciated.

http://tinypic.com/r/1z1tdw9/5

Found a painful issue putting the SPI stacking header on....because the DUE has a male header on it the SPI sits higher when stacked than the rest of the headers. This caused some pins to only have partial...of course because i was doing a CAN project in this occurred on the CAN pins! Not sure what i'm going to do about that, maybe for SPI use i have to recommend removal and swapping the DUE to a female stacking header as well.  Feedback appreciated.  
Dan - www.togglebit.net - Arduino DUE proto shields - Arduino DUE CAN shields

sanzoghenzo

Hi all, CAN and arduino noob here...
Fisrt, thank you for the great job done, it always makes me happy seeing so much people involved in open projects :)
I try to make up my mind for a project that uses CAN to talk to pioneer IP-Bus.
Am I restricted to SN65HVD234 transceivers in order to use this library? Or can I use a MCP2551-I/P (to be able to use a breadboard and eventually simple soldering)? Should I write a driver for it?
Thanks for the attention.

Collin80


Am I restricted to SN65HVD234 transceivers in order to use this library? Or can I use a MCP2551-I/P (to be able to use a breadboard and eventually simple soldering)? Should I write a driver for it?
Thanks for the attention.


You can use a tuning fork, a ball of twine, and a pair of jumper cables if you want. The transceiver takes a TTL signal and turns it into a differential signal for canbus. Use whichever transceiver you want. The reason there is a driver file for the 234 transceiver is that it supports being turned on/off under MCU control. Otherwise the canbus code doesn't need to worry about what the transceiver does at all.

Having said that, the MCP2551 is a 5V device. The Due is a 3.3V device. This is not a match made in Heaven. The MCP2551 will probably accept the TX signal coming from the Due as it will be close to 3.3V and that should be enough to trigger the MCP chip. However, the MCP will be sending back a 5V RX signal and that's bad for your Due's health. You can fix that with a voltage divider but it's extra parts. So, yes, you can use it if you know what you're doing.

LROBBINS

The 2551 can be put to sleep from the MCU (pin 8 = RS pulled HIGH), but I think you would need voltage shifting to make it work reliably with the due.  Ciao, Lenny

sanzoghenzo

thank you so much for the information. better stick with the SN65HVD234 then!

Go Up