Building a CAN API for Arduino DUE

lufegimenez: Hi everybody!

I`m quite new to the Arduino world, but not to the uC world. I'd like to collaborate as much as possible with the development of the CAN API for the Arduino DUE. I actually have several DUE and other Arduino boards (with the necessary shields) and USB CAN interfaces, as well as other applications that are extensively using CAN BUS.

I'm very sorry of not having been able to start collaborating with you earlier, but I really would like to help as much as possible in any task you give me.

Cheers!

Lufe

Except we can't contribute or do anything, it's really fun this way...

zabaat, What you're saying is partly true, until the new CAN library is published. The Atmel engineer that developed a prior CAN API for the SAM3X8H, is supporting Arduino with this CAN interface for Due. Once the library is on github, everyone should start to test/discuss/contribute. And I say partly because at this very moment people in this forum could be contributing, let's say, with the design of the shield. Electric schematics have been published here. I have also shown a couple of my shield approaches. What I would like to hear in this post is: My pseudo CAN shield is ready. Here a picture of it, but I have yet to see any of them here. Does that really matter? Yes, because otherwise, you can't do any test or discuss or contribute just with the sketch or the classes. Am I right?

Palliser: zabaat, What you're saying is partly true, until the new CAN library is published. The Atmel engineer that developed a prior CAN API for the SAM3X8H, is supporting Arduino with this CAN interface for Due. Once the library is on github, everyone should start to test/discuss/contribute. And I say partly because at this very moment people in this forum could be contributing, let's say, with the design of the shield. Electric schematics have been published here. I have also shown a couple of my shield approaches. What I would like to hear in this post is: My pseudo CAN shield is ready. Here a picture of it, but I have yet to see any of them here. Does that really matter? Yes, because otherwise, you can't do any test or discuss or contribute just with the sketch or the classes. Am I right?

Oh, I guess I was waiting the same way, thinking what use is a can shield in my efforts to contribute to the testing when I have no sketch or classes. Since it's now clear that is what I need to do to get access. I will build the shield as you have listed and post it's picture. I have had 20 of the chips and 4 Dues for a couple weeks now, definitely would have built this had I known.

I already posses a good understanding of the protocol, USB-CAN adapters and debugging software tools to tackle this. I even have a project that needs it.

I would suggest making a closed project at least for people that understand it is in beta stage so you can control the feedback you get.

I'm in the same position as Zabaat.

I'll build the Pseude shield ASAP and post pics. Maybe I try out another HW solution from the IC I have right here. I would also like to be collaborating with a beta release and feedback you directly.

Cheers

Lufe

lufegimenez: I'm in the same position as Zabaat.

I'll build the Pseude shield ASAP and post pics. Maybe I try out another HW solution from the IC I have right here. I would also like to be collaborating with a beta release and feedback you directly.

Cheers

Lufe

Lufe - I'm working to build a better "industrial protocol" arduino board, integrating modbus / rs232 (12v) and CAN and 2x Due chips. I just saw Palliser's ethernet addin and am debating adding that in by exposing those pins off of the dues for future expansion for profinet if possible. Is this something you would be interest in collaborating in?

Hola Lufe.

Your CAN experience will surely be very useful. As I mentioned in my first CAN post, my humble role is to channel the efforts to let the CAN API be completed. So far, I must say, it has been more a behind-the-forum work between Arduino, Atmel and me. Tests are in progress; the CAN library is working using the IDE directly (no makefile) and we are close.

From all of this, we have learned a big lesson: DO NOT (I repeat) DO NOT try to build something from Atmel Studio ASF and introduce it into Arduino. Both software architectures are entirely different and it shall be a pain to remove unneeded references. This experience is helping us to understand better how to create a Due library. The updated libsam will be solid ground for future developments for Due. Saludos!

Palliser: Hola Lufe.

Your CAN experience will surely be very useful. As I mentioned in my first CAN post, my humble role is to channel the efforts to let the CAN API be completed. So far, I must say, it has been more a behind-the-forum work between Arduino, Atmel and me. Tests are in progress; the CAN library is working using the IDE directly (no makefile) and we are close.

From all of this, we have learned a big lesson: DO NOT (I repeat) DO NOT try to build something from Atmel Studio ASF and introduce it into Arduino. Both software architectures are entirely different and it shall be a pain to remove unneeded references. This experience is helping us to understand better how to create a Due library. The updated libsam will be solid ground for future developments for Due. Saludos!

Some good news some bad news, good to hear but can you explain the part from "Not trying to port Atmel Studio ASF to Arduino Software architecture a little bit more for me for better understanding.

zabaat: Lufe - I'm working to build a better "industrial protocol" arduino board, integrating modbus / rs232 (12v) and CAN and 2x Due chips. I just saw Palliser's ethernet addin and am debating adding that in by exposing those pins off of the dues for future expansion for profinet if possible. Is this something you would be interest in collaborating in?

Zabaat (and everybody else too, of course)

I'm developing for several projects I'm involved in a multifunctional shield with RS485, TTL UART, CAN BUS, TTL digital GPIO, discrete open-ground outputs, relay module and Analog Input port, for the MEGA board. CAN BUS is based on MCP2515 IC, but I would absolutely prefer to use an internal CAN peripheral, therefore I'm following very closely the evolution of the Due board. Testings of this board will start middle February and if everything goes ok, I'll be presenting it soon.

As I told in my introduction, I'm not an Arduino expert nor a programmer guru, but I really would like to collaborate with any interesting project like the one you are presenting.

Estimado Palliser I'm looking forward to test as soon as possible this CAN library. Being able to have direct access to CAN from a CortexM3 processor... :stuck_out_tongue_closed_eyes: this sounds sooooo good!!! I'll get today all my 3.3V CAN transceivers, I'll mount them tomorrow or Monday and I will have my DUE CAN test bench available for you!

Cheers

Lufe

Lufe, Thank you. I will be waiting to see your shield!

Markus, I am being the spokesperson of the Atmel engineer who is supporting us, and Massimo (of course). As you may know, I ported the CAN files from ASF to Arduino IDE but, because of the AFS structure, it took over 20 files to make the interface run. This is not under the Laws of Arduino. Arduino should be simple, beautiful. All the time, in this post. Massimo's retort has been: use few files. For this project, Atmel is using some non-ASF drivers they had before the ASF era. They explained to me that if we include any ASF based file in the project, there will be needed to add thousand others. I know you did a great job with your RTC Library but in the case of the CAN class, more references need to be considered.

Hello all, firstly I am new to Arduino, but am eager with the anticipation of Canbus for the Due as it will serve my application well.

While I can understand why some of you may require a shield to provide easy connectivity with a Canbus interface and the arduino due, could I ask what would be wrong with using something such as the below link for a canbus development module that appears to be quite cost effective to me + my application? I presume it would still work with the upcoming Due library?

SN65HVD230 CAN Board Network Transceiver Evaluation Development Module Kit 3.3V http://dx.com/p/sn65hvd230-can-board-network-transceiver-evaluation-development-module-150782 http://www.wvshare.com/product/SN65HVD230-CAN-Board.htm

To those developing the canbus library, keep up the good work, your efforts will very much be appreciated I'm sure as it will bring the simplicity of the other numerous other libraries to this very capable processor.

(not to be pushy, but do we have a timeline of when we may see a beta library, or an initial issue?)

Thanks in advance Rob

Hello Rob and thank you for your encouraging words!

I checked the electric schematic of the SN65HVD230 based board you mentioned. It can work with the CAN library but in a direct mode. I mean, pin 8 (Rs) is been underused and fixed to ground (high-speed mode). The CAN library contains the SN65HVD234 component data conforming to Arduino API that will be sub-utilized too (I think you don't want to port the manufacture ones).

I would recommend it only for tests purposes, but for your application, you will surely want to migrate to 234 to take advantage of the Due libraries for ultra-low current sleep mode. Additionally, the missing filter and buffer capacitors should be needed if distance between Due and CAN device increases.

In case you decide to get it, I would also recommend to get two for loop tests of the CAN controllers. Notice that the manufacturer's (Wave Share) price differs considerably from the vendor's (DX) (Russian?). By the way, I don't see the 120 ohm terminal resistor in the photos. Only the 10K, I think. Regards!

Here the schematic of the SN65HVD230 based board you mentioned.

Palliser,

the 120k resistor is positioned to the left hand side of the end of bus jumper pins (between the CANL & CANH markings on the Waveshare board).

Thanks very much for your points regarding ultra-low sleep current mode, and the filter & buffer capacitors, i'll defiantly keep it in mind and can see the advantages of the 234 over the 230.

With regards to "pin 8 (Rs) is been underused and fixed to ground (high-speed mode)", looking at the datasheet for the 230 (link below), I don't think that this module / interface board is actually set for full high speed mode, as it has a 10k resistor before the ground connection, and reading the datasheet, this seems to imply that it is actually set up in slope control mode (pg 20 of datasheet) as ~ 15V/usec, does this not imply that it is actually not in full high speed mode? But I may have misunderstood the datasheet (is slew rate not related to the bus frequency?)

http://www.ti.com/lit/ds/symlink/sn65hvd230.pdf

Many thanks again,

regards Rob

Rob, You are right. Sorry for overlooking the 120 resistor and the slope mode. According to the specs, the high-speed mode of operation is selected by connecting pin 8 to ground or lowering of V(Rs) to 0.0v < 1.0v (p.2,3). So, no high-speed. I believe the manufacturer sets the board to 'slope' as a typical mode that helps to improve EMC behavior (spikes, harmonics) in case we use an unshielded bus cable in order to save some money, but, the trade-off is a loop propagation delay around 100ns with 10K (p.22,23). Anyway, you may reduce the baud-rate to 250 or 500K if necessary. regards.

Palliser: They explained to me that if we include any ASF based file in the project, there will be needed to add thousand others. I know you did a great job with your RTC Library but in the case of the CAN class, more references need to be considered.

Thanks for the laurels, but the RTC stuff isn't as half as big as the CAN stuff you did and btw. there was an "component_rtc.h" file that was waiting for me and begged me to make an userfriendly (under arduino law-standing) Library. For you there was nothing from arduino to work above it.

Is there hope of the code seeing the light of day soon? There seem to be no fewer than 3 people (4 including me) who could be working on creating a library but instead it's languishing behind the scenes and no code has been posted. This is kind of depressing since there have been mentions of posting code for around 2 months. It's all well and good to want people to create shields but some people are programmers and some people are electrical engineers. The two don't always overlap so asking people to build something for the transceiver interface isn't always realistic. The four pin adapters posted in this thread would be fine to use for testing if we had code. It doesn't even have to be nice code or complete. Something that works is sufficient to get started. It seems like somebody has code that at least partially works since I've seen mention of testing for a long time. What is really stopping the placement of that code on github? There seem to be no shortage of volunteers to work on it. Just saying...

I would have to agree with AdderD. Why can’t preliminary code be posted up for people to start digesting/optimizing/learning/testing/developing? Also, this API that’s being ‘developed’. There hasn’t even been any discussion on how this API will utilize the CAN peripheral and other necessary peripheral features on board the micro.

Let me elaborate: From my experience with micros and peripherals, there are many ways to configure the drivers. Sometimes you can use DMA, sometimes there is dedicated RAM on board for the specifc peripheral, or you might not use either. There’s all kinds of Low Power Mode Options just for CAN. What events will be generating CAN interrupts to the uC?
What exactly is this API establishing? A bare bones CAN driver or are there more layers of software queuing on top?

So why are driver configuration options not up for discussion? The driver is the foundation upon which everything else will be running. It seems as though there should be discussion on this, unless Palliser wants only his CAN driver ideas implemented…

Another "let us code" post here - I don't particularly care how the CAN shield turns out, and it's not going to have any effect on what the CAN API looks like. It's getting to the point that someone is going to fork off and make their own CAN library, but if the efforts happening behind the scenes of this thread are the "officially blessed" efforts, it would be a shame to have conflict in the future.

A GitHub repo with a "This code does not work." line in the README should suffice.

I think, at this moment, an overview of this project would help to clarify and provide some answers for the latest posts:

My original goal was to find a tinker way to communicate the two little "CANRX" and "CANTX" of the new Arduino Due. I did read in the Arduino site that there was no API available for that. I ran through this forum and found nothing in progress. I asked Massimo about it and he invited me to contribute doing so. I started to look for prior arts regarding the integration of SAM family cores and the CAN protocol and found SAM3X-EK development board and Atmel ASF CAN library. This forced me to re-align my original goal with Atmel's goal which is: to show how to configure the two CAN controllers and how to manage CAN message transfers. Then I started to port the Atmel sample to Arduino IDE. I worked alone for a month, posting my progress here in the forum. During this exercise, I didn't imagine that this way was the hardest road. Finally, I made Due to read/write CAN messages, but at a cost: ~40 files (50% Atmel, 50% Arduino). Even though I followed Massimo recommendations trying to minimize the library, I couldn't reduced them too much. So, I asked him and Cristian for help. They did put me in contact with the Atmel engineer that developed the CAN sample. I gave him the files and he started to redo pretty much everything. As I mentioned before, he already built the shield and is doing now tests. He is a leader, an expert with CORTEX-SAM and a hard worker.

Like you guys, I am waiting for the final CAN API. In the meantime, my role these days has been to motivate the making of the shield, which is a must.

All I can say is that Arduino want to release a solid CAN API, providing to this community a good start in working with the CAN protocol. It is a fact that not everyone knows CAN, like some of us. In this way, it will be easier to digest/optimize/learn/test/develop the protocol. And that's when you will be very valuable with new ideas/applications and supporting others that want to learn. Thanks.

Palliser, I did not mean to be critical. People are ready to go on this, and I think it’s time we start working towards a goal. It sounds like the Atmel engineer may have higher priorities or slowed down on progress, maybe we should start working on our own CAN API. What would we need outside of the datasheet to do this?

Yes, I don't mean to sound like a jerk but that point it really looks like whatever is happening behind the scenes is not working. I really seriously am considering starting up an effort to make a new library from the ground up with just Arduino sanctioned code and libraries. It seems like this Atmel person isn't working very quickly. It is true that it appears as if the canbus stuff in the cortex chip isn't the easiest to work with but the Arduino 1.5.2 IDE seems to already have plenty of libsam and CMSIS stuff in it so access to the relevant hardware features to enable canbus should be possible. At first a fresh effort like this would just basically be the ability to send/receive canbus frames without a lot of hand holding but eventually it could be built up. We'll see. I should get my Due soon and transceivers some day and once I get my hardware I'm going to be itching to make things. If this Atmel guy hasn't produced anything by then I might take matters into my own hands. It's OK if my effort doesn't get sanctioned or if I end up abandoning it once/if the sanctioned one sees the light of day. I'll still have learned a lot about the architecture and that's important too.