Board für komplexes (?) Projekt gesucht

[Mxt]

1) Spricht irgendwas gegen die Arduino IDE?

Grundsätzlich nichts. Außerdem kann man ja mit den gleichen Boards auch Alternativen nutzen.

Allerdings steht in Deinem Ausgangspost

Debuggen soll natürlich gehen

Kein Arduino außer dem Zero hat eine Hardware-Debuggerschnittstelle. Die Arduino IDE hat sowieso keinen Debugger, man kann die Boards aber z.B. mit Visual Micro seriell debuggen.

Das ist auch ein Merkmal des Due. Kein anderes Board in der Preisklasse des Original Due kommt ohne Debuggerschittstelle.

4) kann man die angesprochenen Biliotheken für den Mega auch für den DUE einsetzen ?

Der Due hat einen Prozessor mit einer ganz anderen Architektur. Alles was direkt auf Prozessorregister zugreift muss angepasst werden. Falls das jemand für die entsprechene Library gemacht hat, dann läuft sie. Sonst nicht.

[HaWe]

Der Due hat einen Prozessor mit einer ganz anderen Architektur. Alles was direkt auf Prozessorregister zugreift muss angepasst werden. Falls das jemand für die entsprechene Library gemacht hat, dann läuft sie. Sonst nicht.

genau das macht doch die Arduino-IDE, unter Verwendung von gpp, den AVR und arm libs, board specs und der Java-Shell, die all das verwaltet. Alle libs, die auf ANSI C bzw. C++ benutzen, werden von gpp auf die entsprechende Zielplattform kompiliert: das ist ja gerade der Vorteil von C/C++ code mit den dazu passenden Compilern, die ja vorhanden (installiert) sind.

In den meisten Fällen, die ich kenne, sind die gpp libs für avrs beschnitten (z.B. stdio.h), um Speicher zu sparen (z.B. sprintf() für floats, oder auch generell vsscanf(), das für AVR überhaupt nicht zur Verfügung steht), für den Due sind diese Beschränkungen aufgehoben.
Das gleiche gilt für Variablentypen: bei AVR sind max. 32 bit Variablen möglich (auch double wird auf 32-bit float herunterskaliert), der Due hat 64 bit double und 64 bit long long (int64_t).

Ich kenne keine einzige Einschränkung, die für den Due gülte, aber nicht für avrs. Ausgenommen sind ntl Hardware-Register-Zugriffe, aber ich kenne auch hier keinen Fall, in dem dann nicht entsprechende Alternativen für den arm gäbe.
Selbstverständlich kenne ich nicht alle libs, die es geben mag.
Halt, gerade im Moment fällt mir 1 ein:
tone() funktioniert noch nicht beim Due. Allerdings hat er 2 DAC on-board, um wav von SD wiederzugeben, habe aber beides noch nicht wirklich gebraucht.
In der Liste des TOs lese ich aber nichts, was solche Einschränkungen erwarten ließe (CMIIW).


als Ersatz für einen richtigen Debugger muss man bei Arduinos die serielle Konsole am PC verwenden. Hier kann man immerhin während der Laufzeit Variablen mit ihren Werten tabellarisch ausgeben, und man kann manuelle Brakepoints setzen, wo man auf einen Btn-press wartet.
Etwas hölzern und steinzeitlich, ok, aber man kann sich damit behelfen.
Allerdings mache ich das lieber als gdb auf anderen Plattformen zu benutzen - dieser Debugger ist für mich WIRKLICH die Hölle...!

[Mxt]

Also erst mal vorweg: Ich will dem Fragesteller den Due nicht ausreden, er soll seine eigenen Erfahrungen machen. Vielleicht ist der Due ja ganz richtig für ihn.

Der Due war auch mein erstes Board mit 32-Bit Mikrocontroller. Allerdings bin ich kurz danach auch an ein anderes geraten (mbed LPC1768 ).

Im Vergleich (mittlerweile mit 5 verschiedenen mbed Boards) fallen mir dann doch einige Sachen ein, die mir am Due missfallen. Hier nur die wichtigsten:

Performance: Das Problem mit dem Linux auf den Cortex-A Boards hast Du gut beschrieben. Allerdings besteht das in ähnlicher Form auch beim Due. Die Arduino Software bildet halt eine Abstraktionsebene, damit sich der Due wie jeder andere Arduino anfühlt. Allerdings ist die Verpackung ziemlich dick. Das erste was einem beim Vergleich mit einem mbed auffällt, ist der Geschwindigkeitsunterschied. Manchmal nur 20-30%, bei anderen Sachen gerne mal Faktor 5.

Einschränkungen in der Software: Die Beschränkungen beim g++ für die 8-Bitter stammen von den Compilerbauern, mehr gibt die kleine Hardware halt nicht her. Beim Due ist das anders. Wir hatten hier kürzlich eine Frage zu C++11 auf dem Due, ich bin gerade zu faul den Thread zu suchen. Da musste ich auf eine alternative Buildumgebung verweisen, weil in der Arduino IDE Teile der C++ Standardbibliothek des Compilers gelöscht sind, die bei der Stand-Alone Installation dabei sind. Dadurch sind diverse C++ Features (z.B. string, vector, usw.) künstlich deaktiviert. Technische Gründe dafür gibt es nicht, wenn man die Sketches außerhalb der IDE baut funktioniert es und die Programme sind teilweise kleiner und schneller als mit der Arduino IDE.


Also noch mal zusammengefasst meine Erfahrungen zum Due:

Ein großes Board mit vielen Pins, besonders hervorzuheben zwei analoge Ausgänge, sonst gibt es meist nur einen.

Die fehlende 5V Toleranz finde ich für ein Bastelboard als Mangel, bei allen meinen anderen sind mindestens die digitalen Pins tolerant. Das ist auch ein Problem mit dem CAN-Bus am Due, weil ich meine MCP2551 von den anderen Boards nicht nehmen kann, die arbeiten mit 5V.

Das Preis/Leistungsverhältnis ist etwas dürftig. Ein 13 Euro ST Nucleo mit auch 84 MHz hat fast genauso viele Pins und ist mit mbed deutlich schneller. Und den Nucleo gibt es auch mit 100 und 180 MHz. In der Preisklasse des original Due gibt es z.B. das FRDM-K64F in Uno Größe mit 120 MHz Cortex M4F, 256 kB RAM, 1 MB Flash, Ethernet, SD-Slot und 16-Bit Analogeingängen (2 davon differentiell).

Wenn man viele Libraries braucht, ist man bei Arduino besser aufgehoben. Standardsachen wie SPI usw. bedient mbed ausführlicher. Die Arduino Software erscheint doch etwas als Black Box. Bei mbed kann man viel einfacher in den Quellcode eintauchen.