Go Down

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

Collin80


Hi all,

I recently started following this thread and I was trying to see if I could get it to work on my own. I cant, however , seem to get the examples to compile and I keep getting the following errors.

CAN_EchoTest.ino:7:21: error: variant.h: No such file or directory
In file included from C:\Users\jhsieh\Documents\Arduino\libraries\due_can/due_can.h:72,
                 from CAN_EchoTest.ino:8:
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:34: error: 'uint32_t' does not name a type
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:37: error: 'uint32_t' does not name a type
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:39: error: 'uint32_t' does not name a type
etc...

I'm sure I have done something obviously wrong. Can anyone point it out?


Hmm... variant.h does exist. My guess is maybe you aren't using the proper Arduino IDE (you need 1.5.2 or newer) or that you forgot to set the board to Arduino Due (programming or native port).  Otherwise, you do have the library installed to the proper place so it should work.

Collin80

I posted another example (a traffic snooper). But, does anyone have any other requests or suggestions? Maybe an example of how to do PID requests and parse responses for OBDII? I'd like at least some of the examples to be useful right off the bat for various things instead of being pointless demonstrations of features.

jwhsiehum

So originally I noticed I needed to update arduino and I did, but my stupid self forgot to switch the board back after updating. Thanks for the help!

RPieter

Hello Collin,

Respect for doing this. I will read this topic in more detail ASAP, because I am now using a UNO with a CAN-bus shield. To use the DUE will be a big inprovement.

Thanks! I will give you feedback and I am willing to help further develop this. You can always PM me if you need help with something. I am not an expert, but  maybe there is something I can do.

Pieter


I have just pushed a commit to github. There are two examples now (as opposed to the previous four) but they show how to use the library now. Word of warning: If you update to this version of the library you will very likely need to update your sketch. Some things have changed. The function to get frames (get_rx_buff) now takes a reference parameter instead of a pointer. This should be easier for most people to use. There are now easy functions for sending frames, receiving frames, and setting filters. There is now less need to directly call low level functions or have to mess with the interrupts. A lot more things are handled within the library now. Additionally, all can frames now use CAN_FRAME instead of having different versions for RX and TX. CAN_FRAME now uses a union for the data bytes so you can directly set things 1 byte, two bytes, 4 bytes, or all 8 bytes all at once.

I have done various tests and this version of the library seems to properly send frames in both standard and extended mode. I have tested reception of standard frames but haven't tested reception of extended frames yet. Both included examples have been verified by connecting a Kvaser Leaf Light to a dual canbus board to scope the traffic.

More changes are coming soon. I'll also create a document that details how to use the new functions.
Let's make it !

coryjfowler

I've read most of this topic, then started skimming though it as troubleshooting questions took up most of the posts.  I wanted to clarify some things and also add to the discussion about the MCP2515 CAN protocol controller that has been used on the ATmega328 among other legacy Arduinos as I have experience with it.  At some point I, if someone else does not try to first, want to make it interoperable with the Due's CAN library so more than two transceivers could be used with the Due.  I suspect after the modifications I recently made to the MCP2515 library that it might work now, but I do not have a Due, yet, to test with.

As for J1939 and other High-Level "CAN" protocols.  Those should be ENTIRELY supported with the CAN controllers on the Due.  I've used the ATmega328 with the MCP2515 to interface directly with J1939 systems.  J1939 really is just a specification to make smart engine sensors and components work between manufactures.  It transmits extended CAN IDs and 8 data bytes.  The only catch is, you have to figure out the CAN ID from the PGN and source address which is not that hard.  If you have access to a list of PGNs and SPNs, you can figure out a lot of what goes on in a J1939 bus.  I used J1939 at my employer, and I have become very familiar with it.

I also want to say that support for higher-level protocols should be made in an additional library that takes use of the CAN library.  There is no reason to add high-level bloat to the low-level library that not everyone will want or need, but that is my opinion.

As for what IC should be implemented on the Due CAN Shield, I would really like to see the 235 used because the ability for auto-baud selection without sending errors to the bus would be very useful to me.  I would also suggest that the standard CAN pin-out be used if a DE9 is put on the shield.
"Taking the time to make a proper, punctuated, post is a mark of courtesy and respect."  http://forum.arduino.cc/index.php?topic=149022.0

Go Up