Hello Downtown_sausage, Yes. I wrote two sample sketches based on an Atmel sample for the SAM3X-EK. Currently, I am receiving direct support from Atmel/Arduino. They are adjusting some path needs and setting the correct dependencies before releasing it on github (Arduino libraries). At the end, all the drivers (including the transceiver one) should be into libsam of future IDE releases. Regarding your excellent initiative to build the driver, I don't know how easy could be to start from scratch a can driver for the SAM3X8E. The Atmel CAN controllers are hard-to-tame for me if compared with other (remember that there are a lot of MCUs out there with Cortex-M3 core and embedded CAN controller like STM32F10XX). It requires an orchestrated initialization between PMC, AIC, CLK and CAN controllers. The main idea is to build a consistent CAN library to take advantage as much as possible of features like interrupt/message handling, timing, wakeup/sleep, producer/consumer modes, etc... It's about a short time to have available the library but....it's up to you, feel free to contribute with your skills. And thank you!

I see. I haven't looked at the Atmel CAN example drivers yet, but from my experience, chip manufacturer's code is generally pretty rubbish. If we want legitimate CAN applications for the Arduino, we will need to have an extremely solid base driver interface to work off. Don't want to build a house on a weak (inefficient) foundation.

To clarify my last post, I suggest we don't use Atmel's CAN drivers and instead work them from scratch. But if they are really good, then no need to mess with them. In reality, it will probably be a task of looking what they did and seeing if we can improve upon their driver implementation. If it's anything like the CAN processing on the PIC24/PIC32, you can probably offload much of the CAN receiving messages to a DMA channel, which will be key for efficiency. This could be done with TX too, but may not benefit too many applications. I should probably start reading the Atmel uC manual to see how they implement this stuff.

downtown_sausage we're working directly with the ATMEL engineer who wrote the examples in the first place. I suggest you coordinate with Palliser who we have put in touch with the engineer. there is a good chance to get the info straight from the source.

1. CAN controller -> DISABLED after power-up reset.2. CAN controller clock -> ENABLED by PMC (via Low-Power Peripheral Bridge) for CAN peripheral IDs 43 (CAN0) and 44 (CAN1). 3. CAN controller interrupt line -> ENABLED for mailbox X (API definition - CAN_IER_MBX) through CMSIS definitions (CANx_IRQn) in the embedded NVIC (NVIC_EnableIRQ).4. CAN controller initialized 4.1. CAN_BR register (baudrate) -> SET. The following steps are performed: 4.1.1 Check whether the baudrate prescale will be greater than the max divide value. 4.1.2 Check whether the input MCK is too small. 4.1.3 Initialize it as the minimum Time Quantum. 4.1.4 Initialize the remainder as the max value. When the remainder is 0, get the right TQ number. 4.1.5 Find out the approximate Time Quantum according to the baudrate. 4.1.6 Calculate the baudrate prescale value. 4.1.7 Get the right CAN BIT Timing group. 4.1.8 Before modifying the CANBR register, disable the CAN controller. 4.1.9 Write into the CAN baudrate register.

4.2. 8-CAN message mailboxes -> RESET. (CAN_MB_DISABLE_MODE) The following steps are performed: 4.2.1 Check the object type of the mailbox. If it's used to disable the mailbox, reset the whole mailbox. 4.2.2 Set the priority in Transmit mode. 4.2.3 Set the message ID and message acceptance mask for the mailbox in other modes. 4.2.4 Set up mailbox in one of the five different modes. 4.3. Configure a mailbox in reception (or consumer) mode 4.4. CAN autobaud listen mode -> SET in CAN_MR register (CAN_MR_ABM == 1) 4.5. CAN controller -> SET CANEN in CAN_MR register (CAN_MR_CANEN == 1) At this stage, the internal CAN controller state machine is reset, error counters are reset to 0, error flags are reset to 0 and starts bus synchronization automatically by scanning eleven recessive bits an then start listening to the network (real world).

I want to clarify that, even though the above initial procedure it might look over-elaborated, the nature of the CAN controller so requires. We, mortal thinkerers are used to a higher level language. My aim has been to bring here part of what's cooking regarding the CAN API, now in progress. But don't worry; at the end, a simpler solution to this whole approach will emerge.

Note: The CAN interruptions in SAM3X8E are implemented through CMSIS definitions in the embedded NVIC inside Cortex-M3 (Not from not existent AIC controller). I got confused because it would seem that some of the CAN controller sections in the SAM3X8E manual (doc11057) were from copy&paste sections of the SAM7X manual. The explanation could be that CORTEX-M3 inherited part of its functionality from the venerable ARM7.

For all those who have followed this post, I would like to inform you that we still working very hard building the API and runing tests, with the valuable help of Atmel. For obvious reasons (Christmas and New Year) we had few latencies but I hope that, as soon as possible, we will publish the library and sample sketches in github. On the other hand, I think it is timely and appropriate, to see from those that already have built their DIY pseudo CAN shields, to show us their progress. Thank y'all again for your patience.

Thanks for the update, I have my samples in but now I need to get a board to solder them to. My goal is to make my own board but that won't happen until I recover from my broken foot. Meanwhile I'm getting everything that I can ready to help with the testing.

Hi that_kid. I am sorry to know about your broken foot. Just take it easy. Even thou I have my shield working OK, I still looking for a better out-of-the-shelf board that fits better the design. I am also working on some eagle files to build, at some time, my own design. Remember that for the two transceiver we are going to need 8 pins of the Arduino DUE (CANRX0, CANTX0, CANEN0, CANRS0, CANRX1, CANTX1, CANEN1, CANRS1). For my tests, I didn't use the EN and RS pins. I just connected them to +3.3 and ground respectively.

Hi that_kid. I am sorry to know about your broken foot. Just take it easy. Even thou I have my shield working OK, I still looking for a better out-of-the-shelf board that fits better the design. I am also working on some eagle files to build, at some time, my own design. Remember that for the two transceiver we are going to need 8 pins of the Arduino DUE (CANRX0, CANTX0, CANEN0, CANRS0, CANRX1, CANTX1, CANEN1, CANRS1). For my tests, I didn't use the EN and RS pins. I just connected them to +3.3 and ground respectively.

I've been lurking on this thread since you started it. I would be happy to collaborate on the Eagle files and even fab a board as this fits with my plans. I would be happy to produce a run and share the rate with the good people here. My board would integrate modbus via MAX485 as well with very little extra cost. I also would love even a very beta copy of your sketch if possible.

Hi zabaat. I am very happy for your interest to contribute on the CAN shield development. At this very moment, 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 hope to get soon a feedback from Atmel about their tests (they are building their own DIY pseudo CAN shield). I also expect to receive next week a couple of DUEs I ordered almost two months ago to do some networking tests. Regarding the sketch, as I mentioned before here, it should be available in github on the next days. You could start ordering the parts and building your own shield to be prepared to run tests once the API is released to public. Finally your idea of the gateway is very good knowing the need to integrate CAN with other protocols. Just hold it until the time comes. Regards!

Hi that_kid. I am sorry to know about your broken foot. Just take it easy. Even thou I have my shield working OK, I still looking for a better out-of-the-shelf board that fits better the design. I am also working on some eagle files to build, at some time, my own design. Remember that for the two transceiver we are going to need 8 pins of the Arduino DUE (CANRX0, CANTX0, CANEN0, CANRS0, CANRX1, CANTX1, CANEN1, CANRS1). For my tests, I didn't use the EN and RS pins. I just connected them to +3.3 and ground respectively.

Thanks Palliser, I was also thinking of building my own board as well. I have some other parts I want to add for other functions from the DUE. In the meantime I'll just get a small board that I can mount the transceivers to for testing. The good thing about not being able to move around much is that I can think more about my designs.

Hi All, I'm very excited about this project and I'm constantly watching this thread for news and source.BTW what we did here http://arduino.cc/forum/index.php/topic,135403.msg1064848.html#msg1064848 may be very helpful for the project Have a look.I'm planning to use a debugger too with the arduino , but that is still a working in progress. Happy new year at everyone Zad

For those that already have in mind an automotive application for the Arduino Due and the almost ready for release CAN API, while it seems to be too early, I believe is timely for them to start seeking out as much information as possible of the CAN protocol of their vehicles and get familiar with it. For example, the specific type of CAN standard and some specifications like CAN identifiers, Bit rate, message type (default 11-bit identifier?), data format, range definition, etc... I must say, during some tests, often, I had to stop my test and spend a considerable amount of time searching for needed CAN info. Oh, I forgot: try to get an OBD-II male connector (plug) and where is the OBD-II connector located in your car (Most are located under the steering column).

I wanted to show, briefly, how I started building my second DIY pseudo CAN shield. I decided to use two SN65HVD235 transceivers in order to compare them with the two SN65HVD234 I used in my first shield. For these 235s I also used a different SchmartBoard: The model 206-0004-01, and instead of keep it intact, I did cut it. Here a picture of the two 235s soldered in the SchmartBoard, with pin headers and a pinout.

***********WARNING: This pinout corresponds to the SN65HVD234 transceivers. Not the 235 ones**********

I wanted to present it here, for those that have not started yet their shield, as an example to be followed using the previous schematic I published in this post. Even thou 234 and 235 transceivers are very similar, differ in the pin 5. For the 234 this pin corresponds to EN (enable) for an ultralow-current (50-nA) sleep mode and for the 235 this pin 5 corresponds to AB that implements a bus listen-only loopback which allows baud rate synchronization.

Notice that this second CAN shield, more than a shield, will work as a side car (alone or inserted in a bread board) unlike the first one which is a true shield. I made it that way to avoid soldering work. I hope to be uploading more pictures of my progress with it.