Go Down

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


I'd call the current state of the canbus library "just barely operational enough to be useable." And, I say that being one of the people responsible for it.  It does include a total mish-mash of API formats. I suppose the proper answer to your question is that it's still in a state of significant development and, yes, migrating to a more Arduino friendly format would probably be a good thing. The library is used in a project of mine and I think we added a couple of convenience functions that maybe didn't make their way back into the library but either way the library is a mess. I had always meant to go back and clean it up but you know how that goes. It works so nobody ever quite gets back around to making it pretty. I do still want to fix it up though.


Thanks Collin, for such an honest appraisal.

Within the next few months, I plan to work on a new CAN library for different hardware.  I had hoped to work towards compatibility with a well-defined official Arduino CAN API.  Seems such an API is still some distance in the future?

When talking about APIs for Arduino, it's usually good to refer to Arduino's style guide.


Bringing up new hardware AND designing an official API (implementing and testing on Due as well) might be more work that I can realistically take on?  Then again, I'll need to implement something for an API.  I really do care deeply about compatibility.  I know from experience that starting without an API plan usually results with an API deeply rooted in the hardware's specific details.  From what I can see, it looks like the Atmel guy did this, then you've been adding the higher level stuff?

My hope at this point, if you and others are willing, would be to discuss what the final, official Arduino CAN API might be, in a perfect universe where we all had plenty of time to actually work on the code?

I've been reviewing the existing CAN APIs.  So far, I've found 3 Arduino libraries: this one, Seeed's for their MCP2515-based shield, and ChipKit.  Seeed's API is fairly simple, just 8 public functions.  ChipKit's API is horribly complex.  The other API I've seen which seems the most Arduino-like, is mbed's:


I'd like to ask a couple specific API questions...

#1: How do you feel about using a special typedef or object for message data, versus primitive types?  Currently Due, Chipkit and mbed use these.  It does allow passing more info together, like the ID, length, timestamp.  But it also doubles the API, from just one object that communicates to 2 objects, with more stuff to learn to create and extract the data.

#2: Does providing mailboxes in the API add more benefit for users than the increase in complexity and overall size of the API they require?  For many Arduino users, the ease of learning is key.  An API with fewer than 10 functions, where all have simple names, seems approachable.  Seeed and mbed don't expose mailbox functionality.  Due and ChipKit have APIs with dozens of functions and long lists of constants.  So my question is whether mailbox access (rather than simple read & write) is really beneficial for some uses, and what those applications might be?


I made a quick PCB layout for the schematic in message #33.  Here the shared design, if anyone's interested.



Any progress on this effort?

What can be done to help?


Any progress on this effort?

What can be done to help?

Sorry, I haven't gotten around to working on the library in some time. I do hope to get back to it soon.

At this point what needs to happen is for someone (me, you, someone) to create a sensible API that we would then follow. The way it works currently is very convoluted and silly. You shouldn't need to know so much about the hardware to use the library. Paul had wanted to do all of this a while back and things just sort of fell by the wayside - probably my fault.  He had mentioned looking at the APIs for things like mbed. That's probably a good idea. Ideally we'd have an API where you initialize a canbus port by giving the speed and then you can set the filters in an easy way and send frames just by giving an ID, whether it is extended or standard, and the data bytes. There should be a structure or class that we use for canbus frames. It probably would be easiest if we used the same structure/class for both RX and TX frames even though they've got slightly different info (RX frames have no priority while TX frames do).


I am still planning to work on this.  Since mid-November, a number of things have happened.

PJRC released Teensy 3.1 on December 9.  Obviously my main interest is developing a library to support CAN on Teensy.  I do want to work towards a really good, hardware-neutral API, even if that means getting somewhat involved in redesigning Due's library.

So far, the only real "work" I've done on CAN is buying and building hardware.  I built up that little circuit board for Due, and a CAN interface board for Teensy 3.1, and I purchased a couple MCP2515-based modules and connected them to the other Teensy boards.  As you can see, I've been putting together the hardware side for working on a CAN library.....


Paul. I'm watching this intently, but helping would be way beyond my skill level.  My main interest in this is automotive, and specifically motorbike at that.  I already have an Uno with Sparkfun CAN shield which I've used to monitor and subsequently decode much of the data on my Ducati Multistrada. An easy to DIY teensy solution will address my current space issues. 

P.s. Excuse the slightly arrogant user name, it up was one that I used on a Ducati forum so dealers wouldn't link the posts back to me and then deny and future (unrelated) warranty claims!


I have some experience with the MCP2515 with both the ISO and the J1939.

I built logger and gateways using the UNO and the 1284P.

I also have access to buss analysis tools and would be willing to help out as needed.




What bus analyzer do you use?  I've been considering getting one of these, but mainly because I have their USB analyzer that works quite well.


Truth is, I have pretty much zero experience with CAN bus.  But I do have 20+ years experience developing with microcontrollers and several years on Arduino libraries and code.

I could use a little advice about what to do on the CAN side of things.....


I use the Vector CANALYZER PRO with J1939 option.

These are pretty expensive and I have tried to replace this with some small micros.  I have 4 gateways running with UNO's right now.  $80 bucks ~$2000.


Any help is greatly appreciated, you guys are the greatest. I just want to send and receive one message in 11 bit and 29 bit. When I change the example DUMMY_DATA to 0x1234 and 0x5678, I get some kind of endian format  with number pairs reversed. And the 29 bit message header is always 0. I can't get the message header for 29 bit. I have a seeeduino shield to monitor also. The seeeduino receives the right bit header, but not the Due. It also does not seem to send the 11 bit correctly. I tried to clear codes on my car but was not successful. The message never got interpreted by the ecu correctly.
Would someone be able to post simple code that I can analyse? I only want one mailbox to send, and then receive for 11 and 29 bit - all masks will do.
I too am watching this forum closely. I agree that the code should be simplified, like seeeduino with less concern for the Due internals.


I put in an order for the OSH Park Arduino Due CAN Test Board.
Does anyone have a parts list or link to a shopping cart (jamco, mouser, digikey) I can use for the can transceiver, resistor, caps, and DB9 header.
I am fairly new to surface mount components and am not sure what physical size components were used in the design.
I already have a DB9 to OBD adapter from the UNO can shield.


Yes pm me. Fwiw I finally have a production run of shields on order and I can share some of my prototyping stuff and parts list.
Dan - www.togglebit.net - Arduino DUE proto shields - Arduino DUE CAN shields


I put in an order for the OSH Park Arduino Due CAN Test Board.
Does anyone have a parts list or link to a shopping cart (jamco, mouser, digikey) I can use for the can transceiver, resistor, caps, and DB9 header.

Yes, here you go.  I also updated the description at OSH Park.

Code: [Select]

    Qty   Digikey P/N       Description
    ---   -----------       -----------
     2    296-27991-1-ND    CAN transceiver
     2    445-7660-1-ND     Capacitor, 10uF, 805
     2    399-1170-1-ND     Capacitor, 0.1uF, 805
     2    609-4003-ND       DB9M connector
     2    CF14JT120RCT-ND   Resistor, 120 ohm
     2    3M9447-ND         Header, 2 pin
     2    3M9580-ND         Jumper


Ok, it seems I had to send three times to the ecu before it responded.
id = 0x7DF
databyte[3 to 7] = 99
global send three times in succession did the trick. I guess my jury-rigged shield needs help.

Go Up