Arduino Due Mini/Nano

@DuaneB @graynomad

Thanks for the suggestion.

BTW we can discuss other Arduino compatible products and call them by name, I was just objecting to a couple of messages that were basically advertising while the topic is about discussing other formats for the Due.

m

Constantin:
Hi Massimo and thanks for stopping by.

First of all, many thanks for your time, efforts, and so on that it has taken to get the Arduino project as far as you and your team have. You've single-handedly transformed what used to be a clubby atmosphere in the embedded systems market with the excitement of open-source IDE's/hardware, excellent documentation, great boards for people to begin learning electronics on, etc. That's a huge achievement and the number of competitors imitating you is I guess a nice compliment.

That said, and I don't want to be rude, but where are we off-topic? We're comparing the Due to its competitors, it has features they don't and vice versa. Similar conversations go on all over the forums, comparing various Arduino boards to each other. Are you sensitive to the discussion of a competitors' product?

Many thanks again for all the work that you and your team do to push the Arduino business forward.

thanks for the kind words :slight_smile:

BTW I don't "stop by", I live here :slight_smile:

As I mentioned we can freely discuss any compatible board/competitor and what not. I was just objecting to a post that was basically advertising while I was more interested in the discussion around what other formats the Due could have.

m

I for one would like to see a Due the size of a Uno. I don't really care that I won't be able to use all the pins. Heck, most of my advanced projects don't even use all the pins of a standard Arduino. I however do need the extra processing power, speed and memory of the SAM3x chip.

If more IO is needed, I can always buy or build expander shields based on SPI, I²C or plain old shift registers. :slight_smile:

I've looked at other memebers of the same family with a smaller package that wouldn't require a huge amount of porting.
it would be possible to make a Uno sized board with one of those.

m

As an example of design, look at the STM32F4-Discovery, you will see that they made 2 rows of pins on each side of the board. It is not bread board friendly but, the board "in inches" is only 2.6" x 3.85". The Uno is 2.1" x 2.7" (not counting USB connectors on either board). The STM board has some extra features that could be removed to make it a bit smaller, and still have room for another USB connector. This board format will allow for all the pins to be accessible for use and shields could be made to fit it also.

A reason I do not like the board, is because the male pins were soldered in by the factory and I can not seem to remove them without damaging the board. The solder they used seems to have a extremely high melting point. I would have preferred no pins installed or female headers installed.

I spend my time with Arduino because I love the ease of programming Arduino provides and I am grateful the Due is out! I am waiting for mine to be delivered.

Hello Massimo

A question: why did you choose the SAM3X8E and not the lower pin count 3X8C? Wouldn't the latter be easier for smaller boards since it has 44 pins less while still retaining most of its features?

K.R.
Jo

I would start by looking critically at the Leaflabs Maple for ideas on what an Uno sized board should be (and maybe the Chipkit Uno32 as well), and at the Maple Mini and Teensy 3.0 for ideas of what a nano sized board might incorporate. For a nano, I'd think one, maybe two mini usb ports, and that's it -- and the rest of whatever IO is broken out is on breadboard pins.

I've programmed the Maple, and I quite like them, I think they are quite an elegant design in many ways. (Of course, it's in it's third major release revision by now, so there's been time to get a few things sorted out.) The one gripe I have is the limited capacity of the board power supply -- you have to manage the board power very carefully if you want to power any external devices as well. Certainly more finicky than something like an Uno to work with, but they work very well and are very reliable once you get them setup properly.

Obviously, a nano sized board using the same chip as the Due would make no sense economically, even if it were physically possible to fit. If a peripheral isn't broken out on a dev board, it might as well not be there. And the smaller the dev board, the more limited the number of pins for breakouts. So why would you pay for an expensive chip if a cheaper variant will effectively give you the same functionality?

So I think the idea of a Due mini/nano is somewhat wrong-headed to start with. An arm-based mini/nano perhaps, but a different beast entirely to the Due.

Massimo, thanks again for the insights. It's great to hear from you and I look forward to the new direction the Arduino team is taking making ever-more powerful processors accessible to the general public. It would be great if you or other folk on the leadership team could consider commenting from time to time elsewhere on this site regarding decisions such as the non-adoption of Pauls suggestions re: malloc.c to fix the Strings library once and for all.

I didn't mean to sound like an advertisement re: Pauls teensy, BTW - I have no financial stake in PJRC, etc. just a customer of a single board while I have bought several official Arduinos. I simply admire the board for what it is, a full-blown 32-bit ARM processor on a tiny footprint that is easy to breadboard.

The Due features an incredible processor that offers way more options than the current board footprint seems to have space for - unless you start mounting components on both sides, I suppose. External RAM, Ethernet, etc. to name a few.

Something to consider is how risky releasing a native-only USB product can be. Presumably a mini-size Due would have only 1 USB port. Adding the 2nd port, for a HardwareSerial interface based on the well-tested 16u2 firmware was a very smart move for Due.

The USB software is tricky to get right, times 3 operating systems. Almost everybody takes this code for granted when it works well. But USB is complex. Years ago, I spent many months on Teensy 1.0 to get it working reasonably well in Arduino, and that was after a few months developing the bootloader. Even with Teensy 1.0 in late 2008, the first couple dozen boards had a bootloader bug... one where I sent apologies and free boards. The Maple guys also spent many months perfecting their USB stack. ChipKit went through a painful processing trying to wean themselves off of Microchip's code (I'm not sure which they're using now, haven't looked recently), and so far they're used a FTDI chip as a solid platform for loading code. Leonardo was delayed many months, while difficult USB bugs were resolved. Even Arduino Uno R1 had a couple USB bugs in the 8u2 firmware using Dean Camera's long-established LUFA stack, involving timing of control requests on linux. Even many vendor-supplied USB stacks have bugs, which sometimes go unnoticed because fixed-function products don't hit them, or get redesigned to work around the bug, or very experienced engineers fix the bug (but never share the fix, since it's a proprietary product). I just recently spent about 6 months doing it all over again from scratch on the Freescale chip used on Teensy 3.0, and let me tell you, doing a DMA-based stack is even more difficult. The thought of some previously-unknown USB bug turning up keeps me awake at night....

It's easy to underestimate the difficulty of perfecting a USB stack. When you create a mini-size board with only a single USB connector as the only way of loading code, the software bug stakes are high.

And then there's this guy:

http://jkdevices.com/arduino-megamini

not particularly mini, tiny or teensy, but it does get the full sized TQFP chip on there and manages to get all the pins broken out, in a form factor that looks comparable in size to an Uno. Mini for a Mega, I guess!

Yet another interesting mini ARM dev board:

http://www.kickstarter.com/projects/kuy/galago-make-things-better

also:

http://outbreak.co/galago

The thing that sets this apart is the IDE hardware debugging using JTAG and gdb. (I'm intrigued enough that I've actually preordered one. Must. Stop. Buying. Dev. Boards. Just. Because. They. Look. Interesting.)

I was wondering if the DUE might not have JTAG based debugging with it. Are there any firm future plans for hardware debugging on an Arduino ARM based deg board? I seem to remember discussions where this was going to be on the agenda for the DUE (a NZ-based developer of a debugger product springs to mind), but I guess it got left out under time pressure to get it out the door. Or are the technical difficulties deeper than that?

Hardware debugging would be a very nice feature. Obviously.

Notice that the LFBGA144 package for the ATSAM3X8E is twice smaller than the actual LQFP144 of the Arduino Due.

LFBGA144
10 x 10 x 1.4 mm

LQFP144
20 x 20 x 2.4 mm

Here a picture of both together with the Arduino DUE.

The trouble with BGAs is that you need about 10 layers to get the pins broken out. They are nice and small though.


Rob

While it does indeed have a compact footprint, I don't see much advantage to the BGA version here.
Especially because if a nano version is of interest, the pinout would contribute far more to the total area of the board than the uC itself. That said, if a smaller chip AND fewer pins are the way taken, then SAM3A4C and SAM3X4C, which are 100-pin variants from the same family, might be options as someone mentioned earlier.

Graynomad:
The trouble with BGAs is that you need about 10 layers to get the pins broken out.

And then the board cost goes up a lot ...

... and the ability of folk to roll their own boards based on those chips go down. It's hard enough and expensive enough to get a 4-layer board made...

[quote author=Massimo Banzi link=topic=128707.msg975441#msg975441 date=1351512035]
A small factor Due is in the list of boards that will come out.[/quote]
Good to hear.

[quote author=Massimo Banzi link=topic=128707.msg975441#msg975441 date=1351512035]
There are a number of issues to solve ... for example with such a big processors it becomes hard to make something that would fit into a breadboard without removing access to most of the pins.[/quote]
Removing access to pins is generally a bad idea; if a smaller chip doesn't provide a feature, fair enough, but if the chip does provide it and it is not broke out then this is frustrating, because SMD pins are so tiny so wiring directly to the pins is hard.
On the other hand, it may be worth examining whether breadboardability is a primary requirement for a small form factor. Breadboards with their parallel rows of connections impose a constraint on the PCB that is not needed or helpful. If a 'Nano Due' could be connected via multiple rows of solder holes (or pins, or sockets) around the periphery the more pins could be broken out.

Since that is one of the defining features of the original Due then I would say yes, its important to keep on a Mini/Nano Due. For example, people might prototype and develop on an original Due, then use a mini/nano Due to mount permanently in the completed project.
There is also the possibility (and this is not without risk, but should be considered) to break away from the 2.54mm/0.1" grid spacing for sockets, and to make a range of small boards with smaller pitch (1mm?) sockets and corresponding small-pitch shields.

I think that you lose some features with the SAM3X8E but I can't find a good comparison chart right now.
Atmel just released asf 3.5 and I got a sd card/Fatfs api working on a SAM3X-EK so that is exciting.
My goal is to get a standalone json/cgi server running, I think that can lead to some really cool "Internet of Things" applications.

What is the priority: Due Mini vs Due Net? Due Net would seem to be a little easier hardware wise but integrating FatFs/lwIP/SD card drivers might be a pain.

Regards

The due mini/pro version is already out there :slight_smile:

http://www.geeetech.com/wiki/index.php/Iduino_DUE_Pro