Is Arduino Due coming?

bperrybap:
Is the DUE is using a compatible shield footprint as the Uno/Mega?
If so, Is the DUE 5V tolerant on the inputs?
Or are users potentially going to be burning up inputs when they attempt
to use their existing 5V shields on the DUE?

In other words, if the DUE is backwards compatible with existing shields,
how do you prevent users from damaging their DUE when plugging in 5V shields?

--- bill

That was discussed by several of us in this or possible another Due based thread. I believe some of us feel that many a new beginner will most likely (or at least potentially) suffer damage from using non-Due compatible shields. Venders of shields will probably have to be burdened to state with their shield offerings if their shield products work with Due only or older arduino + Due or older 5vdc arduinos only. I don't see a good case for why they didn't give the Due a whole new shield footprint to work with?

Lefty

retrolefty:

bperrybap:
Is the DUE is using a compatible shield footprint as the Uno/Mega?
If so, Is the DUE 5V tolerant on the inputs?
Or are users potentially going to be burning up inputs when they attempt
to use their existing 5V shields on the DUE?

In other words, if the DUE is backwards compatible with existing shields,
how do you prevent users from damaging their DUE when plugging in 5V shields?

--- bill

That was discussed by several of us in this or possible another Due based thread. I believe some of us feel that many a new beginner will most likely (or at least potentially) suffer damage from using non-Due compatible shields. Venders of shields will probably have to be burdened to state with their shield offerings if their shield products work with Due only or older arduino + Due or older 5vdc arduinos only. I don't see a good case for why they didn't give the Due a whole new shield footprint to work with?

Lefty

From the SAM3X datasheets...

Voltage on Input Pins
with Respect to Ground....................................-0.3V to + 4.0V

So the IC's I/O pins certainly can't take 5 VDC logic. I suppose it's possible for there to be optional FET based level shifter circuitry for each I/O pin, but it's very unlikely they included it on the stock Due...

retrolefty:

bperrybap:


In other words, if the DUE is backwards compatible with existing shields,
how do you prevent users from damaging their DUE when plugging in 5V shields?
--- bill

That was discussed by several of us in this or possible another Due based thread.


I've seen a few discussions on this.
I was wanting to hear a definitive answer straight from the horses mouth, somebody
on the Arduino team, perhaps Massimo Banzi
as most of the discussion about this that has happened so far is from/by folks that don't have access
to the real product and as such is speculation on what will/won't be in the final version
of the product.

--- bill

retrolefty:
I don't see a good case for why they didn't give the Due a whole new shield footprint to work with?

I really don't think there is one. I suspect this decision to continue with the "legacy" shield footprint for the "Due" will be recognised in hindsight to be a significant blunder, as well as an opportunity lost.

I've been arguing for ages that the current backplane arrangement leaves a lot to be desired and when I first heard about the Due I hoped there would be a change. No such luck.

I guess it's hard to orphan 500+ existing shields, but if some/many/most of them won't work anyway it doesn't matter.

I think that "How many will work?" is the $64 question.


Rob

@pico

As I just mentioned this is the first board with the SAM3X we're going to release so there is plenty of opportunities to create different layouts (as a matter of fact we have a new layout we've been playing with for a while)

I think there is a lot of people who prefer to re-use as much as possible of what they currently have before they have to throw everything away.. Our current Eth and Wifi shields, to mention two, work with the Due as they are able to detect and adapt to the whatever voltage the main board is operating at.

Making the board 5v tolerant would have made the it way too expensive. The market is now full of heavily subsidised (even sold at loss...) products that make it quite difficult to fight these battles.

The beauty of open source is that in a few days time you will be able to download the Arduino Due eagle file, design a much better layout and sell your own boards benefiting from our lack of vision :slight_smile:

@Graynomad
we introduced the R3 layout a long time ago and we explained why the IOREF pin is there... some people understood and implemented the correct measures to make their shields compatible, some others didn't ... you'll see a lot more shields made available with the full implementation of R3

m

@Massimo
The due is a completely new hardware platform which needs a new toolchain. From the video's I have seen on this subject I learned that the new Arduino IDE has been optimized to support more toolchains. As you may know I have developed a Arduino eclipse plugin that uses the Arduino IDE toolchain. When the due comes out I will change this to "a arduino eclipse pllugin that supports multiple toolchains".
As such I am very interested in how you support "configuring a toolchain in the new arduino IDE". I assume this is done based on an additional hardware folder that contains it's own boards.txt file.
I also assume that this boards.txt fie has been extended to allow to identify which toolchain must be used and which options must be set for which tool.
I would love to get a description of the new boards.txt. I have been searching but didn't find anything on this subject yet.
Can you point me to a description that would allow me to take the right decisions to implement "toolchain selection based on Arduino IDE info" in eclipse?
Thanks

Best regards
Jantje

Jantje

Next week we release IDE v 1.5 and there will be a blog post discussing some of the internals of the new version.

m

Will IDE 1.5 rollback the removal of errors for missing include files that happened in 1.0.1?

I don't have specifics on that.. as I said there will be a blog post

1.5 will be Due only at the beginning. shortly after there will be a 1.0.2 with some of the enhancemens backported (there are some nice user experience improvements in it)
Later on when 1.5 is stable we'll merge and have only one IDE.

if you can point me to an issue here Google Code Archive - Long-term storage for Google Code Project Hosting. I'll have it checked.

m

It's Google Code Archive - Long-term storage for Google Code Project Hosting.. It was introduced in 1.0.1, and it really needs rolling back. It causes a lot of problems, particularly with inexperienced coders.

Graynomad:
I guess it's hard to orphan 500+ existing shields, but if some/many/most of them won't work anyway it doesn't matter.

Exactly. No-one is going to "throw out" their old shields just because they've bought a Due, anymore than they'll throw out their Unos and Megas. Why would they? The AVR product line still has a future, and the the ARM products complement rather than replace these products. Even if Arduino never made another AVR-based board, the old 8-bit AVR Arduino "ecosystem" would now continue indefinitely under its own momentum.

The problem with the IOREF pin approach is that adds complexity (and therefore cost) to any shield design that wants to use this technique. Cheaper and simpler to design an AVR 5v version and a separate ARM 3v3 version, if needed (I suspect many if not most shields will be suited for either AVR or ARM rather than for both). The fact that a lot of people are going to be buying shields designed for AVRs and finding they don't work for the "Due" is going to cause endless aggravation that could have been avoided, I suspect. I hope I'm wrong.

The reason I believe this is an opportunity lost is that, while anyone can design a dervative board with an alternate header layout, only Arduino is in a position to set a new "standard" layout by simply releasing a new product. So no, remedying the "lack of vision" is not quite that simple.

This is encouraging. Could I suggest soliciting some feedback from the user base before settling on a final design? Who knows, you might end up with something even better. :wink:

But in reality how much shield re-use will there really be? (I'm guessing not much)
There are many things that will prevent existing shields from being used.

  • 5v outputs driving the Arduino input pins
  • depending on certain alternate being functions on certain pins
  • Current demand on Arduino output pins
    being some of the biggest issues.

Normally when electrically damaging incompatibilities exist,
connectors/pinouts/headers are changed to ensure that such devices
are never allowed to be connected to each other.

Just my opinion but preserving the existing header layout is creating a much
bigger problem than it is trying to solve.
It now makes the selection of which shield to buy/use no longer simple as there
will be shields that will plug into the DUE that can damage it.
Not good for newbies and less technical users who will tend to have the view
that "if it fits" it must be ok.

Making the board 5v tolerant would have made the it way too expensive.

Ah. Finally, A definite answer on the 5v tolerant question.

Too expensive for whom? The naive user that blows up his DUE or schools that have
students blowing up DUE boards when trying to use an incompatible shield may not
think the money saved for this lack of protection on DUE was worth it.

There are other 32 bit MCUs out there that are 5v tolerant that would not
have incurred the additional cost that might have been better suited
for this type of environment.

--- bill

Making the board 5v tolerant would have made the it way too expensive.

Too expensive for whom?

Too expensive for what the developers want to sell it for.

Yet another article about the arrival DUE on Monday:

An audio library for the Due is also being released, coupling onto the Due’s ability for wav file playback.

I got super excited when I saw this.

Due retail packaging sighted by ?@HamburgMakers:

A5kCKDjCYAMQKub.jpg

Only one more sleep :slight_smile:


Rob

And so the shield compatibility problem begins. Note the first sentence in the below, does that sound like a beginner might think any present should he might own will work ok with the new Due? Later it tries to explain that all shields may not indeed work with a Due or some can even cause damage, but it's certainly not a crystal clear to this reader what is trying to be explained. However this a article from Wired so not sure if the source is from Arduino or just the writers attempt at an explanation? Anyone ever see an official arduino R3 spec? I don't recall seeing one published, although I'm assuming they means new shields should have that mating connector pin and read the voltage present on the new IOref pin to determine is it's a 3.3vdc signal meaning the controller the shield is attached to is operating at that voltage. Older controllers will not have that pin so no voltage will be sensed by a connected shield board.

The Due will continue to work with all Arduino shields — add-on boards and circuitry like motion sensors and LED light arrays — that conform to the official Arduino Revision 3 layout. However, the Due operates at 3.3V whereas AVR-based Arduinos operate at 5V, meaning some third-party shields that don’t follow the R3 specs to the letter may not be compatible, depending on their voltages. It also means those looking to use the Due in existing applications should adjust their voltage or risk damaging their board.