There's always the Teensy 3.2 with the M4 core, with I believe selectable CPU speed of 72 or 96mhz: https://www.sparkfun.com/products/13736
Here a comment from Massimo Banzi at Arduino.cc (LLC) developers' discussion page:
To me the real problem is the Due has lots of attractive features but many of them are disabled by the board. You can't use the real-time clock properly, the DAC would be 100 times more useful with a 0-5V amplifier, the ethernet pins are inaccessible, I2C has silly pullups (but only on one).
Some different design choices might have pushed the Due in a different direction. The Teensy is much more useful for a bigger range of things, although it's hampered by its desire to be small, so some useful pins are more difficult to access. It also has better library support for USB type things which the Due would also be good at.
I can't see the Due going away. It may not be stocked at Mouser next year but I'm sure you will be able to buy new ones at reasonable prices 10 years from now.
As I said above there is no reason for me not to choose a Due.
In this thread I did compare pure integer compute power of the Due with that of a modern PC Intel processor: http://forum.arduino.cc/index.php?topic=391511.0
Due was factor 92(83) slower, but I was surprised that it was only a factor 92(83) [depending on compiler setting -Os, optimize for size, the default in Arduino IDE, or -O3, optimize for speed].
It would be interesting to just get the runtime reported for the other three (>16MHz) Arduinos in above table, the 101, MKR1000 and Zero.
If you do have access to one of those three Arduinos, could you please flash the sketch from the the thread mentioned and report the reported runtime here?
The Due number is: 548us (-Os) 494us (-O3)
I did some test with the different Arduinos (incl. MKR1000 and Due) and also the ESP8266 and the Maple (STM32). It is not your benchmark, but could give you some ideas.
Thanks Andreas, you made a good point in the comparison, I just did compute the ESP8266-12E (nodemcu dev board) numbers with Arduino IDE 1.6.4. This is the current table:
| model | | -Os | | -O3 | | - | - | - | - | - | | 101 | | | | | | Due | | 548 | | 494 | | MKR1000 | | | | | | Zero | | | | | | ESP8266-12E | | 612 | | 304 |
"-O3" does make a great difference for ESP8266-12E.
Can you please provide the numbers for the MKR1000?
nathancamp provided both Arduino 101 numbers here.
This is the updated table while waiting for MKR1000 and Arduino Zero numbers:
| model | | -Os | | -O3 | | speed | | processor | | Wifi | | - | - | - | - | - | - | - | - | - | - | - | | 101 | | 846 | | 791 | | 32MHz | | Intel® Curie | | - | | Due | | 548 | | 494 | | 84MHz | | ATSAM3X8E | | - | | MKR1000 | | | | | | 48MHz | | SAMD21 Cortex-M0+ | | yes | | Zero | | | | | | 48MHz | | ATSAMD21G18 | | - | | ESP8266-12E | | 612 | | 304 | | 80MHz | | Tensilica Xtensa LX106 | | yes |
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.
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?
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.