Who has one with the RTC Crystal can tell me what on the surface so I can order me one by my self

Btw. the Vcc on the SPI is 5V and should be noticed

On the spi in the middle?, SHIT!, And I have been using this and that.
How can I know if my board is defunct or not ?
I was attaching an unit that is supposed to handle 3v3 and 5v, but I tried mosi++ in the middle, and the same on the edge of the board.

Mixing 5v and 3v3 on an board that is not 5v tolerant is not very nice design!

Yes saw it on this http://arduino.cc/en/uploads/Main/arduino-Due-schematic.pdf.

It's true not an good move to have 5V on an 3.3V SPI some Sparcfun Shields use this Pin to detect the voltage too so they are dangerous too. Can you explain an bit more what are you have done so I can think about it.

But it musst be possible too set each Pin high and low seperatly so you can detect if it works and you can use the pins as intput to check the other way. --> Serial echo

[Please report any errors, and I will fix them.]

Please report any errors, and I will fix them.



Colors indicate comparison to the Mega2560 which has a similar shield connector pinout. Green means the same as Mega2560. Red is for warnings. Orange shows new functionality:

• JTAG and SWD headers for debugging
• DAC outputs
• CAN bus
• Two USB ports
• erase switch

Please ignore the interrupt pins for now, these are not implemented in 1.5 but are planned for 1.5.1 so I will leave them where they are for the moment and revise when 1.5.1 comes out.

revision 2: correct labelling of USB ports, SPI not ICSP header.
revision 3: label JTAG and SWD pins, call out 16U2 ICSP (thanks to PeterVH)

The definitive source remains the official Arduino Due hardware page. This pinout photo overlay is just for convenience.

Btw. the Vcc on the SPI is 5V and should be noticed

The file available on the website is the latest available design file for the Arduino Due.
As far as I know this is the file used to generate the production files.
I will investigate further and update the file if necessary.

Consider that the factory will apply some minor tweaks to our reference design before going to productions (usually with their own CAM software) therefore some minor differences are possible.

A possible answer for b) is that the factory normally has two stages of manufacturing, a first batch where many steps are still sort of "handmade" to make sure the process is smooth then they move on to large scale manufacturing where they might introduce some more tweaks (usually to make it easier for them to do automated testing, optimising the pick and place machine programming )


@graynomad
We're not ignoring anybody. you have to keep into account that we are bombarded by communications from all sided and it's not easy to be on top of everything realtime.

You seem fairly negative in most of your messages, is that anything we can do to cheer you up?

m

That did not explain that the crystal for the RTC is missing

I just received two Due's in today.  They were ordered from the Arduino Store the same day it was listed online.  They both look just like the "current one" in the first photo.

Yes get the same today works like charme

Here's the current version, it's growed a bit.



Link to larger version

www.robgray.com/temp/Due-pinout-1.jpg

My brain hurts from checking and cross checking and it's very likely that there are errors at this point. Feel free to point them out

Note the extra serial port (Serial4?), not supported as far as I can see but there none the less.

______
Rob

Giant work, cool. Can you send the cdr file too?

I looked at the Due PinMapping and saw this:

Due Pin Number               SAM3X Pin Name          Mapped Pin Name

         4         connected to both PA29 and PC26       Digital Pin 4

       10           connected to both PA28 and PC29       Digital Pin 10

I'm confused why are on two Pins joined on an Due Pin for what reason?

If there's any interest I'll continue with it.

there is !

greets

From me too,

put the current from the Pins on it too and it will be damn near perfect

Hello Markus,

I feel happier today because more people want to get involve with me in this journey. I just mentioned the SN65HVD234 as a known option, but agree with you about the autobaud loop-back and standby mode capabilities of the 235. I have also worked with SN55HVD251 and SN65HVD251, but at the end, its about a community-consensus with the permission of Arduino. So, I encourage you to move to the top of your ToDo list to find the best CAN transceiver option for the transmission between the Arduino Due processor (ATSAM3X8E) and the outer CAN world. Please, keep us posted about your tests and progress. Thank you.

Uhh Palliser you trapped in the same hole I was, the Series SN65HVD23x are in some way special.

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.

Palliser

thanks for the exhaustive introduction. I would keep ASF out of this project, no need to add a million lines of code to access the CAN peripheral. We can extract the info from the relevant files.

Please leave Atmel studio 6 out of the development process, making the code available through the IDE is what we need in order to get many people to help out, test and use the code.

Let me know if we need to design a can shield.

keija: the library will be developed and made available here https://github.com/arduino-libraries/arduino-due-can join github if you want to be part.

m

Hello Massimo,

you talk about the ASF, yes the CAN_CAN_EXAMPLE1 is heavy but all what's needed is there all files maybe some more than needed but the component_"what ever".h are from the AFS or not?

About the files where are the comments?

An Shield is absolutely nessesary an transciever chip is needed to get access to the CAN-Bus.

Markus

I've had a request for the Corel file so here's a link to the file for anyone interested.

www.robgray.com/temp/pinout.cdr

______
Rob

Thanks

We already have pinout photo threads:

Yes we do, and that's just another indictment on the Arduino documentation.

Go to probably any other board's web site and there's a nice graphic of some kind showing the pinout of the connectors. Go to the Arduino website and you wind up downloading a schematic and mapping the pins to a data sheet.

EDIT:
Here's one I did for a board I'm working on at the moment



That took me all of 10 minutes to do. Why doesn't Arduino do something similar? Or at least use the photos linked to above.

_____
Rob

How? With what programm?

Hello Lenni. Thank you very much for your encouraging words concerning this initiative to complete the newly created avenue to make Arduino Due to get seriously involved with the CAN standard.

In reference to your first suggestion, as too many of us know, CANopen is a higher level CAN bus protocol. Even thou both use the CAN 2.0B standard for the physical and data link layer, that's it. They differ from the other five layers in the OSI model. I am completely agree with you about implementing CANopen but we are in the incipient phase in building this interface, so, one step at a time. I believe the help from people like you will be needed very soon. I have planned to take advantage of what is inside the ATSAM3X8E, two can controllers that provide all the features required to implement the serial communication protocol CAN as referred by ISO/11898A that includes 1.0 Part A and 2.0 Part B.

In reference to your second suggestion, yes, it will be necessary a couple of transceiver like SN65HVD234 to provide the required transmission capabilities between the differential CAN bus and the CAN controller. I am taking notes of your comments and other comments from this community to keep in mind. Thank you again.

I have interrests to, I would prefer the SN65HVD235 with the possibility off using the Autobaudfunktion without making trouble on the bus. The firm I worked for parttime has many CAN-Bus equipment so I can test.

Implementation of LIN and CAN Arduino Style for the Due is on my ToDo list to get "warm" with the Due.

Hi
Is there a tutorial for the integration of the arduino due in Atmel Studio 6 ?
Or could someone explain me how to do ?

Many thanks
blabeli

Hi the lastest Framework from Atmel 3.4.1 or so has an integration for the Due many examples are on the ASF

I put in a request to enable the ADC15/temperature sensor. However - it is the temperature on the die - which does warm up.
To make it be close to the ambient temperature is going to require implementing a power down mode - no power no die warmup - and then on wakeup reading the temperature straight away.

That seems like a very longwinded way to get a rather inaccurate measurement of the ambient temperature. If you want to measure air temperature, use a temperature sensor that is in the air, not embedded inside a heat-generating device and thermally insulated from the air.

On the other hand, if you need to monitor the on-chip temperature for some reason (like, to raise an alarm if it gets too hot) then that would be a good use of this sensor.

In my opinion it's an good exercise to get "warm" with the new Controller/Board it was similar my first move with the Leonardo figure out how warm is the Controller, for fun not for use...