Arduino Due Mini/Nano

Guys... this forum is about the Arduino Due...
let's keep in on topic

While not a Mini/Nano, I look forward to an ethernet Due. Phy ethernet and SD card can do some pretty awesome things. I have a Sam3X-EK at work for a project and the demo is pretty slick with a rich web interface but the demo is based on BeRTOS which doesn't have a large community and has custom drivers. Atmel just added "native" lwIP support to asf and will add SD card drivers in the next version(November hopefully)
Are the Due drivers ASF-based or from scratch because of licensing issues?

I wonder how the Due firmware would work with the Sam3X-EK, Atmel doesn't even sell the processor(SAM3X8H) on the board.

AFAIK The ATMEL engineers who write all the demo code ported arduino to run on the EK. They don't really use the IDE but a custom makefile.

Arduino Due, on the other hand, is included in Atmel Studio 6.

As I mentioned this Due board is the first in the family

m

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.

I guess that since Masssimo Banzi did not mention the topic of if there was a Due Mini/Nano officially in the works at the present time, then there probalby is not.

I had seen the Teensy 3.0 already at the time I first made this post, and that was why I naturally asked if there were any plans for an "Official" Arduino version with mor guaranteed future Software and hardware support.

As far as the Due Mega+ (Giga?) size factor goes, I will probalby only ever buy one for prototyping and so on. A Due Mini on the other hand more like 3+ for all those flying, walking, roling, swiming things where size/weight is definetely an issue. Never mind all the wearable and hideable stuff.

To CrossRoads:

Start writing up some requiremets, I'm sure it can be reduced to a smaller size.

  • desired size
  • desired power sourcing
  • desired pinouts
  • desired headers
  • desired built-in interfacing
  • etc.

Size: Same as the mini, Perhaps 4 to 8 Pins longer. Just as wide with perhaps a second parallel auter row of pins. I would prefer a rectangular board over a square one. More perimeter to surface area.
Headers: Suggestion: Male headers down for breadboard compatibility, Female headers up for additional pins.
Power sourcing/Interface: USB, Battery 5 to 15V, FTDI would be OK too.
Pinouts: 1.5 to double the amount of the pins on the Mini.

As to which pins... thats where the fun begins. Suggestions? I don't think there will be a please all solution here with all the available capabilities.

J

A small factor Due is in the list of boards that will come out.
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.

Any suggestions?

For example: Is it important to have the two separate USB connections or just the "native" connection would suffice?

m

Hi,
The 'other board' breaks out a set of perimeter pins and then leaves the others accessible through solder pads on the underside, this keeps the size down while providing access to a larger number of pins as an option. It seems like a sensible compromise for new generation boards.

Duane B

rcarduino.blogspot.com

Any suggestions?

Plug it into two breadboards. (no I'm not joking, I see no problem with doing that)

Headers: Suggestion: Male headers down for breadboard compatibility, Female headers up for additional pins.

Leave uncommitted so you can add whatever is appropriate for your application.


Rob

@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.