Arduino Due (released Oct 22, 2012) Compatibility

So, from Massimo's presentation at Maker Faire this weekend, the word is out that the Arduino Due is to finally be released on the 22nd of October for US $49. The board will run @ 84 Mhz based on Atmel's ARM-Cortex M3-processor based MCU (32-bit) SAM3X8E. In addition, it appears Uno/Mega shields will be compatible with the Due too because the form factor has been maintained.

That's pretty exciting for me as it is, especially given that some intensive applications (e.g. real-time camera imaging/recognition) can become convenient now.

But my question is: What about compatibility of libraries/code? -- will they mostly transition seamlessly too? If not, then for any of the enormous number of existing libraries and code to be ported to the new ARM 32-bit MCU of the Arduino Due, what kinds of things will users/library-creators need to do on the software side?

Since I have no experience with ARM microcontrollers or the architectural differences, I am wondering what factors might be involved.

By the way, here is the one-hour video of the Maker Faire presentation by Massimo Banzi & Alf-Egil Bogen:

I think it's a safe bet all of the "Arduino" commands ( will be supported; they will just run a lot faster. However, just as with the existing boards, Arduino functionality can be enhanced or improved by using low level programming and direct register read/write.

from the SAM3U series

It was the 3U at first then they changed to the 3X. Do you know this for sure?

The "core" Arduino library functions should all work, I ported them to an LPC in a few days so they will be able to do similar.

No direct hardware manipulation will work, so any current programs and libs that do that won't run.

I suspect that many existing libraries will break if they deal with hardware.

Many shields will not work as well because the ARM is a 3v3 system. But many should because 3v3 is usually over the logic high threshold for a 5v system so Arduino outputs should drive the shield but 5v shield outputs will give the ARM a hernia.

The ARM being used has so many more features it will be a shame to ham string it by making the Due conform directly to the current header pinout which according to the photos is what they have done. I guess we just have to wait and see.


Many libraries will not work on Due without some effort being expended... The amount of effort required will depend on how dependent the library is on features specific to the AVR, and how well the original author did as making the library "portable."

All those Nth party libraries, written and abandoned by their authors, that broke when 1.0 came out and still haven't been fixed? They probably won't work on Due, either! That shouldn't be surprising.

If you're interested in a particular library, you can probably start asking about it now. Note that not all library authors will have been involved in the Due Beta program, so some of them won't even have tried it yet.

So does the arm chip used in the new Due use hardware floating point math? Seems like some ARM chips have that functionality.


retrolefty: So does the arm chip used in the new Due use hardware floating point math? Seems like some ARM chips have that functionality.


I believe people have said the Duo uses an ARM Cortex M3 chip. According to the spec sheets, that chip does not support floating point. The Cortex M4F chip has floating point (but not the Cortex M4 that was used for example in the Teeny).

True, at last count they were using the SAM3X8E, it doesn't have FP.


@Graynomad: My mistake actually. For some reason, I thought the SAM3X8E was part of the SAM3U "series". the 144-pin, 84 Mhz-capable SAM3X8E is correct.

Reading the datasheet, its very hard going compared to AVR

Duane B

Here is the one-hour video of the Maker Faire presentation by Massimo Banzi and Alf-Egil Bogen:

Yes all these chips are pretty complicated. 1465 pages for the SAM and 448 for the Mega328. Most of the stuff you are used to like UARTs etc aren’t that much more complicated, but then you have the PLL, NVIC, DMAC etc etc on top. Truth is 98% of people don’t need them so at the end of the day it’s not as bad as it could be.

If you have a proper framework this stuff is either disabled or setup well enough to get started. There are gotchas though, on the LPCs the GPIO ports don’t work until you enable their clock, I spent some time wondering why my writes had no affect. Same goes with the other peripherals.

Presumably this sort of thing will not bother any Due users.


It appears the Due provides two USB ports, with one usable for USB host, so e.g., for Android-Arduino communication via Google's ADK... This should be interesting.

How feasible will it be to run a Linux distribution on a 32-bit processor like the Due's SAM3X8E? I'm guessing memory might be a problem, but perhaps there are solutions for that?

With no extra memory I’d say no chance. You should be able to add 16gigMb of external memory but truth is I don’t think that’s something worth doing anyway on the Due, there are plenty of boards around now that handle Linux and I don’t think we need another one. The Due should be good for real real time stuff and hobbling it with an OS defeats the purpose IMO.



RPi for example already provides a straightforwad solution for Linux, but I was asking just to know better.

By the way, when you mentioned 16gig, what is that figure arrived at based on, and what type of memory?

You should be able to add 16gig of external memory

Huh? I don't recall CM3 being able to deal with more than 32bits of address space. Wouldn't that would require an MMU, which CM3 doesn't have? Also, the datasheet says in it's "external memory interface" chapter: "up to 16MB per chip select" and "up to 8 chip selects."

It'd be close, though. The ChipKit MAX32 runs a version of BSD unix, and it's only got 128k of RAM. The SAM3X has "up to 100k" (the retroBSD that runs on MAX32 may be pretty far away from what people expect when they ask about linux, though...)

The chip has

Static Memory Controller (SMC) for SRAM, NOR, NAND support.
NAND Flash controller with 4-kbyte RAM buffer and ECC
SDRAM Controller

So just about any type of memory you like.

As for the size, oops I should have said 16Mb as there are 24 external address lines. But there are also 4 chip selects so that’s a total of 64Mb.

That’s for SRAM, there are extra signals for NAND (Address Latch Enable) so that may be able to address more but I haven’t looked into that.

EDIT: westfw, yes it says “up to 8 chip selects” but I can’t see them on the SMC block diagram, it only shows NCS[3:0].

ANOTHER EDIT: It does show NCS[0:7] in Fig 24-1 and table 24-1, so I guess they are there somewhere. That would make a total of 128Mb.


How does the due ARM processor compare to AVR32 UC3 (as seen in speedwize? Is the ARM actually a lot faster?

No idea, I don't know much about the Xmegas.


@ io53:

You can use the Atmel tables for comparison:

Here is the table for the AT32UC3 lineup:'',category:'34864[33180[33080]]',pm:!((i:8238,v:!(0,18)),(i:8394,v:!(0,17)),(i:8362,v:!(1,28)),(i:8282,v:!())),view:table),sc:1)

And here is the table for the SAM3X series:'',category:'34864[33177[39581]]',pm:!((i:8238,v:!(0,18)),(i:8394,v:!(0,17)),(i:8362,v:!(1,28)),(i:8282,v:!(0,1,2,3,4,5,6,7,8))),view:table),sc:1)

There's a fault in those links. If you cut and paste the whole test into a broswer it works though.