Board für komplexes (?) Projekt gesucht

[FlyRider]

HaWe: mal wieder nicht übern Tellerrand gesehen, richtig?
Im übrigen würde _ich_ nem Einsteiger vom DUE immer abraten, da er völlig anders aufgebaut ist, ist er lange nicht so easy zu handlen, grade du, HaWe hast darüber ja schon etliche Liedchen gesungen. Auch deshalb ist er in der Community recht selten vorhanden, und man findet eben dann auch weniger Unterstützung.

Der Due ist per Arduino-IDE absolut nicht anders zu händeln als der Mega, bietet aber viel mehr zusätzlich (Multitasking plus >10x schnellerer cpu-Takt und SPI plus >10x soviel Speicher plus 2x I2C...plus..plus...)
(Wäre dann also Endstand 2:2 )

ps,
die Due-Probleme sind, wenn überhaupt, Probleme bei Dingen, die es beim Mega noch nicht mal gibt, weil er die Features gar nicht besitzt und man gar nicht so weit kommt (USB-Keyboard z.B. - was anderes fällt mir momentan gar nicht ein)....
ok, 5V Shields passen nicht drauf, die nicht 3.3V kompatibel sind, aber bei vielen Geräten ist es genau andersrum (Displays, BT HC-05) , da ist der Due wieder im Vorteil.

Tja.... ich kann ja zur Entscheidungsfindung nichts beitragen. Deshalb als abschließenden Bitte folgende Fragen:

1) Spricht irgendwas gegen die Arduino IDE?
2) Ich nehme mal an, dass die Anbindung einer IMU und der Joysticks auch bei 3,3 V Versorgungsspannung möglich ist bzw davon unabhängig ist
3) Welches Shield würde ich vtl. benötigen / praktischischerweise einsetzen können, das es nur mit 5 V gibt?
4) kann man die angesprochenen Biliotheken für den Mega auch für den DUE einsetzen ?

[HaWe]

meine Meinung und Erfahrung (ich habe 2 Megas und 2 Dues):
1) nein, kein Nachteil: zumindest keinesfalls für Einsteiger
2) ja: höchstens die 100% Bezugsgröße für analoge Sensoren oder Potis ist halt verschieden und wird dann nach Dreisatz anders berechnet.
3) Original Arduino Motorshield hat nur 5V, soweit ich weiß - aber es gibt andere Platinen, die funktionieren mit beiden Signal-Levels (habe ich selber)
4) die meisten ja (z.B. PID_v1 oder UTFT u.a.m.), ansonsten gibt es alternative (z.B. Timer-Lib für Mega und DueTimer-lib für Due u.a.m.)

[FlyRider]

@ HaWe, es ist natürlich für mich ein Glückstreffer, dass du Erfahrung mit beiden Systemen hast. Ich interpretier deine Aussage mal so, dass es prinzipiell keinen großen Unterschied machen sollte, welches Board man nimmt.

Nachdem ich schon gern etwas Rechenpower hätte, würde ich mich nun mal für den DUE entscheiden und mir überlegen, welche Komponenten ich dazu benötige.
Ich werd die ganzen Links und Empfehlungen noch mal durchgehen und mal eine angedachte Teileliste zusammenstellen. Dann hoffe ich hatürlich, dass der ein oder andere da vielleich noch mal drüberschauen könnte, ehe ich unnötig Geld verbrenne...

Vielen Dank an der Stelle für Eure umfangreiche Hilfe.

[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.

[HaWe]

auch wenn ich nicht mit deinen Erfahrungen bezgl. mbed-Boards aufwarten kann - bzgl deiner Beobachtungen von Code-Kompaktheit der Due-Arduino-IDE-Executables gegenüber nativen ARM Compilern hast du sicher Recht, das ist aber nichts was Due-typisch ist, das trifft auch auf Arduino-AVR-Kompilate zu.

In 1 Satz: ja, es geht auch sogar noch schneller, wenn man mbed verwendet.
Aber nicht einfacher, wenn man schnell Ergebnisse braucht, nicht alle libs selber schreiben will, und sich nicht mit low level-Compilerproblemen und make file herumschlagen will.
Auch das gilt für alle Arduino-Boards, egal ob AVR oder arm - kein Thema ntl für erfahrene embedded-C-Programmierer, oder die, die es werden wollen.

Auch ich will dem TO nichts ein- oder ausreden, ich wollte nur mit Vorurteilen und Berührungsängsten aufräumen, die den Vergleich der Arduino-ARM-Plattformen (Due, Zero, Tian, 101) mit Arduino-AVR-Plattformen (Uno, Mega, Nano, Micro) angeht:

Zum Thema Geschwindigkeit: hier hat man trotz allem beim Due eine über 10x größere Leistung gegenüber dem Mega (cpu clock, Speicher, runtime-Ausführungsgeschwindigkeit).
Und wegen der hohen Abstraktionsebene, auf der man mit der Arduino-IDE arbeitet, ist es eben kein nennenswerter Unterschied mehr, ob man für AVR oder ARM damit kompiliert.
Und wenigen technischen Nachteilen bei einigen älteren externen Zusatz-Komponenten (die z.B. keine 3.3V Kompatibilität besitzen) stehen jede Menge großer Vorteile gegenüber (Speicher, Geschwindigkeit, Multitasking zusätzlich neben Hardware-Timern und ARM- Hardware-IRQs, und eben 3.3V Kompatibilität für neuere Zusatzkomponenten, die keine 5V-Komp. mehr besitzen), und von den libs, die der TO wohl beabsichtigt zu nutzen, sehe ich keine einzige, die ausschließlich für die AVRs zugänglich wären.


ps,
Anm.:
Immerhin ist 5V ein recht alter Standard, 3.3V ist eher der modernere und IMO eher zukunftträchtigere Standard (alle ARM Boards haben den, auch Raspi und BBB), einige Komponenten nutzen bereits heute sogar nur 1.8V - und für alles andere gibt es notfalls Levelshifter.

[FlyRider]

Hallo an alle,

diskutiert ruhig weiter - ich lerne ja jedesmal dazu ....

Aber um die Diskussion nicht in's Uferlose abdriften zu lassen: Es gibt wohl Argumente pro / contra DUE / Mega, womöglich gibt es auch noch weitere Alternativen anderer Hersteller. Hilft alles nix. Irgedwann muss man mal einen Schritt machen: Ich werde (nicht sofort, aber bald) mir ein Arduino Due holen.

Dazu würde ich noch benötigen :
1 Display - dabei wäre es wichtig, dass das Display mit einigem Abstand zum Board betrieben werden kann
1 kleinen und billigen Analog- Joystick (Link wurde ja schon gepostet, Danke)
1 Möglichkeit, zwei Stellmotoren (können auch MOdellbau Servois sein) ansteuern zu können
1 genaue IMU, die ich anbinden kann

Es wurde ja schon diverse Vorschläge gemacht - falls jemand noch Tipps hat - DANKE!!!

MERCI überhaupt noch mal an alle!

[HaWe]

Display: wieviel Pixel? s/w oder farbig?
wieviele Zeichen sollen dargestellt werden?
(ich persönlich habe nur farbige verwendet, min. 176x220, ca.12 Text Zeilen lesbar in Querformat).
SPI: nicht weiter als 20cm, sonst Geschwindigkeits-Einbruch!

Joystick s. Link

Servos: kenne ich mich nicht mit aus, geht über pwm => in Arduino Playground suchen

IMU: habe ich schon gepostet http://www.mindstormsforum.de/viewto...tart=15#p67401

[FlyRider]

Display: wieviel Pixel? s/w oder farbig?
wieviele Zeichen sollen dargestellt werden?
(ich persönlich habe nur farbige verwendet, min. 176x220, ca.12 Text Zeilen lesbar in Querformat).
SPI: nicht weiter als 20cm, sonst Geschwindigkeits-Einbruch!

Danke für den Hinweis bzgl SPI, muss ich mir den Einbau noch mal genau überlegen, das sollte ich aber hinbekommen.
Farbig wäre schon gut, 176x220 ist sicher OK.