Board für komplexes (?) Projekt gesucht

[FlyRider]

Aber wenn du dich für eine Variante entschieden hast - Mega oder Due - sag Bescheid, ich kann dir ein paar Tipps zu Displays geben.

Hi Leute,

was ist denn das für ein Forum??? Da kommt man kaum mit dem Lesen mit. ....

Also prinzipiell geht die Reise wohl Richtung Arduino, Raspi wäre wohl nur interessant, wenn ich vom "Luxus des OS" auch was hätte. Ich brauch es aber prinzipiell nicht unbedingt, das es sich grundsätzlich um nicht mehr als eine Steuerung handelt, und so ist es eher eine Belastung bzgl. Echtzeit. Und nun selbst mit irgendwelchen echtzeitfähigen Alternativsystemen zu experimentieren steht mMn nicht dafür. Ob nun Arduino Mega oder Due... tja??? Wenn es letztlich bzgl. Anbindung der Komponenten (IMU, Diaplay, Motoren, usw...) egal ist, dann würd ich natürlich das schnellere System nehmen - etwas Luft nach oben schadet ja nie und Parameter wie Stromverbrauch spielen für mich keine Rolle.

[Mxt]

Ob nun Arduino Mega oder Due... tja???

Wobei sich der Due nur lohnt, wenn man wie HaWe ausschliesslich die original Arduino-IDE akzeptiert. Ansonsten gibt es für die Cortex-M auch noch mbed, die Einsteigersoftware von ARM selbst.
Version 2
Preview Version 3
die Auswahl an Boards ist da ziemlich groß
https://developer.mbed.org/platforms/
Insbesondere wenn man mit Ethernet oder SD-Karte arbeitet, merkt man den Unterschied zwischen Controllern mit nativem Interface dafür und den über Arduino Shield angestoppelten Varianten. Mbed 3 kann außerdem UART, I2C und SPI asynchron über DMA abwickeln, da kann der Prozessor währenddessen anderes tun.

Boards wie der Teensy lassen sich sowohl mit Arduino als auch mit mbed benutzen
https://www.pjrc.com/teensy/
https://developer.mbed.org/platforms/Teensy-3-1/

[Rabenauge]

HaWe: mal wieder nicht übern Tellerrand gesehen, richtig?
Grade die kleinen OLED's schaffen abartige Geschwindigkeiten, weil die über nen eigenen Grafikspeicher verfügen. Da kommste mit angucken lange nicht nach, das schwör ich dir. Flüssiges scrollen ist damit überhaupt kein Problem.
Kann man wunderschöne Animatinen mit machen- mein Segway z.B. hat nen grafischen Tacho im Masstab 1:4.
Aufgrund des Gewichts werden die Teile (sind ja nur briefmarkengross und auch nich nennenswert schwerer) meist bei den Multicoptern als Displays benutzt- und obendrein sind sie weit robuster als nen LCD (kein Glas). Verschiedene Schriftgrössen gehn auch, und dimmen ebenfalls. Inzwischen gibts die sogar mehrfarbig, hab ich auch noch keins, fällt mir grad ein....

Das klappt mit den lahmen TFT's (die SPI benutzen) nich mal annähernd...auch wenn da natürlich insgesamt einiges mehr rauf passt.

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.

[HaWe]

geb ich zu - OLEDs mit Grafikspeicher, das wusste ich nicht. Punkt für dich!
Außerdem sind sie wohl auch s/w, also weniger bits pro Pixel, auch weniger Pixel insgesamt, also auch weniger Bytes zu transportieren. Noch ein Punkt für dich.
Könnte also gehen.
Andererseits haben sowohl Mega als auch Due einen SPI-Header - warum also nicht was schnelles nehmen, was man kostenlos mitgeliefert bekommt?

A-Bär:
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.

pps,
und wer mit einem Raspi klarkommt, für den ist sowieso ein Due keine besondere Anfänger-Hürde mehr...

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