Arduino Due Obsolete?

I did contact Andreas (sensorsiot) and asked whether he could determine the numbers for the MKR1000, and he did -- thanks Andreas!

This is the updated table, and since MKR1000 and Arduino Zero seem to have very similar SAMD21... microcontrollers the table can be considered complete:

model -Os -O3 speed processor Wifi
101 846 791 32MHz Intel® Curie -
Due 548 494 84MHz ATSAM3X8E -
MKR1000 1038 825 48MHz SAMD21 Cortex-M0+ yes
Zero - - 48MHz ATSAMD21G18 -
ESP8266-12E 612 304 80MHz Tensilica Xtensa LX106 yes

Summary:
The Arduino Due outperforms the other >16MHz Arduinos integer compute power wise, and is only beaten by the ESP8266-12E.

Hermann.

here I did benchmarks about several tests, both low level and high-level API, and it's clear to see the advantages of the DUE and different ARM-based boards.
Unfortunately the documentation of the libs and the ARM-compatibility is a nightmare!

(second chart table)

a suggestion for improving and simplifying this board:
for the future, please remove the built-in i2c pullups!!
and please implement completely ANSI C / stdio.h compatible libs

  • for USB host to HID keyboards (getchar, gets,...)
  • and for reading/writing SD files (fopen, fprintf, fscanf, fgets, fclose...)
    plus libs for pre-emptive multitasking similar to pthread or to C++11 std::thread !

for the future, please remove the built-in i2c pullups!!

I don't see any i2c pullups on the board. Are you complaining that the library enables them in the chip? That should be easy enough to change (but why?)

and please implement completely ANSI C / stdio.h compatible libs [for keyboards and SD cards]
plus libs for pre-emptive multitasking similar to pthread or to C++11 std::thread !

Those don't sounds very Arduino-like. Presumably they're not hard to add, since the Due code is newlib-based (ie file system code exists, but it's not used, nor are the low-level drivers for any HW implemented.)

westfw:
I don't see any i2c pullups on the board. Are you complaining that the library enables them in the chip? That should be easy enough to change (but why?)

There are two 1K5 pullups (RN5A/RN5B) connected to the i2c pins (SDA(86)/SCL(87)). They are part of a quad RN array resistor located besides the 7CE33Z regulator (besides the square coil)....but why?

-p

Since only Arduino dot ORG is still manufacturing Due, any requests for improving the hardware would probably be better sent to them. They really do seem to be competent and interesting in the hardware side, so perhaps there's some chance these long-standing Due hardware limitations might get fixed? Maybe?

Likewise for Due's software & libraries, but so far the dot ORG folks haven't shown much interest or ability on the software side. Their approach seems to be mostly copying from Arduino dot CC. They're trying to start up a "foundation" that will basically crowdsource open source software development for their hardware products. How well that really support Due or any other boards remains to be seen. I'm trying really hard not be too cynical...

The Arduino dot ORG folks are also making a powerful STM32-based board. At the risk of gratuitous self promotion, I should probably mention a more powerful Teensy is in development with a 180 MHz Cortex-M4F chip. A more powerful ESP chip is also coming. These 3 are probably the near-term future for people wanting more powerful Arduino-compatible boards. The ESP stuff seems to now be maturing pretty well. I have a pretty good idea how I'm going to do the software side for Teensy (you can expect more of the same sort of software support I've always done). It'll be interesting to see how Arduino dot ORG do on software for their first couple boards that aren't related to anything Arduino dot CC ever did.

Oh THOSE SCL/SDA pins. I was looking at the ones to the R3 SCL/SDA connector (which are xxx1 rather than xxx0-3, and don't have any pullup.) Yes, it seems particularly weird to put pullups on pins that aren't specifically dedicated to I2C...

Teensy is no option because of far too few IO pins.
The 50-60 dPins and 12 Apins of a Due (like on a mega) plus 2x i2c + 4x UART plus the RAM and the cpu power are of invaluable advantage.

just the SD file system is missing plus stdio.h keyboard key reading from host USB.
yes, and the built-in pullups in i2c0 are messing everything up (thank God at least i2c1 hasn't got them, too). IIRC, they can't be disabled by software.

ArthurD:
The 50-60 dPins and 12 Apins of a Due (like on a mega) plus 2x i2c + 4x UART plus the RAM and the cpu power are of invaluable advantage.

How does 40 digital pins (20 of them with analog), plus a dozen more on a connector, with 6 UART, 4 I2C, 3 SPI, 2 DAC, 2 USB (one 480 Mbit/sec) sound to you? How about running at 180 MHz with FPU?

programmable with the Arduino IDE?
awesome!
Do you have more details?
is it already available?

edit,
now I understand, you mean what you mentioned above...

Teensy is in development with a 180 MHz Cortex-M4F chip. A more powerful ESP chip is also coming. These 3 are probably the near-term future for people wanting more powerful Arduino-compatible boards.

I thought by Teensy you would mean a current Teensy ARM core board.
https://www.pjrc.com/teensy/

ArthurD:
is it already available?

Not quite. Beta testing now.

yes, I assumed it would be that way.

Anyway:
1st) I would expect full support for the Due board nevertheless,
and 2nd) actually, on the long run, both the Due and all the Teensies will be far too small, too:

Just a Board compareable to the Raspberry Pi or the BeagleBone Blue (Quadcore, 32-64bit, 1GB, 1GHz, ~70-80 GPIOs) would be powerful enough for my requirements (or the vanished Arduino Tre, but also powered then by a quadcore instead):

All Features like GPIOs, I2C, UART, SPI, CAN, HDMI TFT display (+ resolution settings), audio/sound, SD file r/w access, WiFi, BT, USB communication + devices, and everything accessable via the 1 and only simple Arduino IDE.

No makefile, cmake, make at all,
just simple #include the libs which are needed.

Things like the RPi and BBB are nice but they have kind of a downside. Yes, they have very fast processors, much more RAM, etc but one tends to be abstracted a very long way away from the bare metal. The fact that you tend to be running linux means that your latency can be worse than on a Due because anything that happens has to bubble down through all the abstraction layers. Also, I know a lot of people have trouble doing direct access to hardware ports on something like a Due but at least you can. On the bigger stuff there are protection systems as well so you have to write kernel mode drivers for direct access. Anyway, my point is that complication goes up dramatically when you go to those faster, more capable products.

But, if someone built a board with a 2GHz processor, 4GB of RAM, and a boatload of features but they didn't use linux or at least built an Arduino like environment on top I would probably be interested. Some things are fine and well with a Due. Other things maybe could use more power. Yeah, RPi has python so it's kind of similar but really I'd like something like RPi but instead of focusing on video focus on being a direct metal version like Arduino where there is a shiny veneer over top but nothing stops you from going straight to the metal if you want. Of course, as processors get faster and more feature rich they also become more difficult to work with at a low level. But, even a Cortex M7 might work. Those are something like 300MHz aren't they? They've got a lot more features than the M3 in the Due but they're still in a same general ballpark just faster and a bit more feature rich. Heck, even add some externally connected RAM and really up the ante. This isn't quite so stark a change as going to a quad core monster and easier to work with.

some things work with small processors, some don't (neural nets, speech recognition by FFT cross correlation, full-HD multimedia,...)
Using libs on the PI like joan's pigpio, you may work already extremely quick on the Pi's proprietary GPIO pins, and using pthread by thread priorities you can come quite close to real-time behaviour - not to talk about real-time kernels.
OTOH, attaching additional hook-up AVR- and ARM-boards (e.g., Propeller-HAT or even additional MCUs integrated on the backpane as on the BBBlue or once planned on the TRE or even on the YUN) you can have the best of 2 worlds.

All depends on what you intend to do, no question.
For a hen flap a AVR will do, for a neural net a 64bit 1GHz 1GB quadcore might even bend your knees...

The IDEs and the API libs will make the difference in the end.

And not to forget: I am finally not known to be a friend of Linux or Python.
So why not have a bare-metal 64bit-super-quadcore powered by a Arduino IDE?
Or perhaps even driven by Windows 10?

But back to topic:
The Due is highly neglected currently IMO, but eventually: it's already available, and so it's actually not a long way off.

ArthurD:
But back to topic:
The Due is highly neglected currently IMO,

Well, Due has officially moved to Arduino.cc's retired products list. Hard to imagine new development is going to happen for a retired product...

Arduino.org still lists it as a current product and some distributors like Sparkfun appear to be stocking it, so at least it seems the hardware will be still be available for a while (if you discount rumors of Atmel dropping this chip). But the dot org folks so far don't seem to have done any meaningful software development for Due, and their efforts for boards like M0 Pro pale in comparison to the much better software work from Arduino.cc.

It'll be really interesting to see whether the dot org folks manage to publish decent software support for their upcoming products using ST and Nordic chips. As far as I can tell, these are their first products where they can't simply copy from Arduino.cc. But perhaps they'll leverage the already-developed STM32 core library or older stuff from Maple?

perhaps they'll leverage the already-developed STM32 core library or older stuff from Maple?

Don't forget http://stm32duino.com/ where Roger Clark and others have been updating/replacing the old Maple code with much more modern and generally capable versions. I've long thought that what arduino.org needed to do was actively recruit some of the more cluefull developers from the forums. Perhaps they have...
(but it looks like not: STM32F103C8T6 bluepill with HID Bootloader 2.2 problems uploading - Arduino for STM32

well, I have 2 Dues and I'm rather fine with their performance and the number of IOs.
Just a better suppport by Arduino.cc libs and shilelds would be wishful.
Most Arduino shields regrettably don't work on the Due, just on the Uno.

Hi there,

I havent tried to buy a Due in a while now.
When i got mine i was a little put off that it was 3.3v only, and will burn out if we apply a pullup to +5v for example. Some CPU's are 5v tolerant even though they run on 3.3v normally.

But aside from that, it's a pretty interesting board. I hope to start using mine soon. I look forward especially to the 12 bit ADC and also the 12 bit DAC, which dosent come on any other boards.
I just have to rig up a good interface that goes from 3.3 to 5v for some devices i need. I am on my way but it will take a little longer yet, especially since i just got a Mega the other day and want to work with that a little first. That's a really awesome board with lots of i/o's and it is 5v so i can connect all my usual stuff to it.
The memory in that thing is enormous.

MrAl:
Some CPU's are 5v tolerant even though they run on 3.3v normally.
......
I look forward especially to the 12 bit ADC and also the 12 bit DAC, which dosent come on any other boards.

Oh, there might indeed be a board with about the same performance as Due with very good Arduino compatibility & support, with 12 bit ADC & DAC and even 5V tolerance on its I/O pins....

..and providing 80 GPIOs, not to forget... :wink: