Will the Due be a dud?

It could be many things, chip shortages or difficulties with the cross compiler / environment are my guess.

I suspect it's that second thing you mentioned. I suspect trying to integrate the 32 bit tool chain into the existing IDE that also has to continue supporting the 8 bits chips is driving them buggy. It would probably be less effort if they were just to develop a totally independent and separate IDE/toolchain to support the Due.

Lefty

It is a big step from UNO to Due and solid new software -always- takes many times longer than anyone including the programmers wants to believe. Buggy software only takes 10%-25% as long, as long as it or something very similar has been done before.

Just due to the step up, I think give them lots more time. I also think that the smart route on the IDE is that it should not be a one size fits all package.

Just came across a bigger picture of it :-

From:-

You can tell a few things from that pic, assuming there are no components underneath (I doubt they would do that) then hardware wise it's really just a Mega with a new processor.

But the software opportunities should be extensive.

Re the IDE, I seem to recall that debugging was going to be included (and you can see what looks to be a JTAG header on the board), I doubt that would be retro fitted to the existing IDE and frankly programs written for this will need a much better IDE. I'm thinking they will go the same route as Atmel's AS5.


Rob

what's that thing next to the word erase? Its right where it says jtagse1
and from the looks of it, id say it'd use the same ide, why hold the same layout if you need different software? And they may have 5v out since also why keep the shape fitted to an mega if its not compatible with mega shields?

All
If this thing supports debugging I'll have to buy one. Pure for development purposes.
Once debugged it can run on an arduino uno.
I guess that makes already a pretty big market
Best regards
Jantje

Looks like JTAGSEL to me.

If so it's used to select the JTAG boundary scan mode, this would be used to test the board but have no purpose for users I think.

why hold the same layout if you need different software?

What's the connection between the physical layout and the IDE?

And they may have 5v

That will only be possible if there are level converters on the back of the board, possible but unlikely given Arduino's aim to be low price. As retrolefty mentioned before the new IOREF signal can be used for new shields but not old ones.

if its not compatible with mega shields?

With the same pinout there may be problems with people plugging in 5v shields. Due she may go poof.


Rob

I really hope they give up some info soon, just something atleast to think about without all this guessing

I wonder how much of the delay is over compatibility issues?

GoForSmoke
ROFL
But I prefer them to take some time and avoid a 1.0 repeat.
Best regards
Jantje

Jantje:
But I prefer them to take some time and avoid a 1.0 repeat.

This!

With the same pinout there may be problems with people plugging in 5v shields. Due she may go poof.

Will it? Most shields I have seen take their power from the arduino, only if the new board outputs 5V on the same pin will this be a problem.

Will the due continue to have the special "pin spacing"?
I hope not
Best regards
Jantje

Jantje:
Will the due continue to have the special "pin spacing"?
I hope not
Best regards
Jantje

Of couse it will, it's part of the shield standard now and one can't put that toothpaste back into the tube.

one could make a compatibility shield

Most shields I have seen take their power from the arduino,

True, even those that have their own power probably only use it for a motor or servo or some such. So I guess it's pretty safe, just probably won't work.

Maybe we will need a list of those that do, due-compatible-shieldlist.org. Feel like a new challenge Jonathon?


Rob

Almost 3 months later, and Due isn't there... nor is any info from the "core team". Time to conclude it was definitely vaporware ?

Anyone interested in REAL 32-bit solutions for speed and pins ? MPIDE supports both Arduinos and Chipkits. Maple and Wiring decided to merge, but lack volunteers. Which of both alternatives looks more interesting to you all ?

The word on twitter is "real soon now", actually "After Easter" there's supposed to be an announcement.

Which of both alternatives looks more interesting to you all ?

Neither for the moment, personally I'm happy to wait and see what Arduino bring out.

Maple and Wiring decided to merge, but lack volunteers.

One of the strengths of Arduino, so far there has been a lot of people "volunteering" by writing code and libraries. I hope that continues with the Due and although it may appeal to a smaller range of people I think that will be the case. After all a programs written in "Arduino" should run on all official platforms.

Hopefully we will know before long.


Rob

I also think that the fact the chip is smd is a problem for hobbyists.. One feature everyone loves is the 'roll your own' aspect of Arduino.. Through hole is what hobbyists generally want.. And the chips are cheap. I haven't gotten and done any ATTiny chips, but they are supposedly usable for Arduino projects.. And I have seen those suckers for REALLY cheap, even in single units. I'm going to pick up a 40pin AVR, ala Bobduino, as I want more I/o than the 328. It's still through hole, so it's not too intimidating. A board with big resources is great.. But like the mega, I wonder about the impact of using a format that is proprietary in terms of pin layout, the headers are the biggest problem with the design.. They plain suck, especially since they neither mate to a breadboard OR accept wire jumpers reasonably. BAD design... Why keep on making the same mistake going forward? Make a cheap adapter for older shields, publish the new pin layout, done.

Better yet, if you want, leave the dang headers, but also put pins on the other side, so the Arduino board can be directly plugged into a breadboard in the same manner as an Adafruit BoArduino.. Imagine how much easier your prototyping would be just plugging the bugger into a breadboard without a billion jumpers that are unreliable at best due to poor quality headers!