Alternativen zum Arduino Mega: 1.Erfahrungen

rainer_r

Moderator
Alternativen zum Arduino Mega - Arduino DUE und ChipKit Max 32

Wie bereits berichtet suche ich eine Alternative zum Mega 2560. Naheliegend ist der bereits bekannte Arduino DUE aber auch das Board ChipKit Max 32 von Digilent wäre einsetzbar. Beide Board haben das HW-Layout des Mega - mit kleinen Änderungen, die aber für unsere Anwendung nicht wesentlich sind. Ich habe mir beide Boards HW + SW - mäßig einmal näher angesehen und verleiche jeweils mit dem MEGA 2560.
Für beide Board gibt es eine kostenlose Entwicklungumgebung (Arduino IDE bzw. MPIDE) diese kann installiert und getestet werden. Beide IDEs haben vergleichbare Oberflächen und Strukturen - man kennt sich also damit sofort aus.
SW-Ausgangspunkt: die SW (ArduMower oder MR2P) lässt sich unter der Arduino IDE 1.05 (Mega2560) fehlerfrei compilieren.


ArduinoDue_Front_klein.jpg

Arduino DUE
Die HW (IO Input) ist nicht 5V kompatibel, d.h. es müssen bei Module mit 5V Vcc (die wir derzeit benutzen) alle Eingänge zum Mega mit Pegelwandler (5V->3V) ausrüstet werden. Dies gilt auch für den I2C-Bus und die Analog-Eingänge.
Meine SW läuft unter der DUE-IDE (1.5.6-r2) nicht über den Compiler. Es gibt, für mich, bis heute noch unerklärliche Fehlermeldungen. Obwohl die Library-Pfade bei allen IDE-Versionen die selben sind werden Standard-Lib's (z.B. io.h)nicht gefunden. Ich verwende in meiner SW aber auch spezielle Libs die diese Probleme verursachen können. Evt. kommt man bei der Verwendung von wenigen und dann nur (DUE-) Arduino-Libs schneller zu einem fehlerfreien Compiler-Ergebnis.


chipKIT-Max32-klein.jpg

ChipKit Max 32
Das Board ist Layout- und Pin- kompatibel und auch 5V tolerant d.h. man kann die komplette HW und alle Module direkt, wie beim Mega, anschliessen (ausser den Analog-Eing). Es gibt sogar noch zusätzliche 16 IOs mehr. Soweit so gut.
Meine SW hat auch hier Probleme und ließ sich nicht compilieren. Es wurden Fehler angezeigt die sowohl auf den Syntax als auch auf nicht gefundene Libraries zeigten. Ich habe relativ schnell aufgegeben die Fehler zu finden und zu beheben. Hierzu müsste ich das Programm wieder in einzelen Module zerlegen und praktisch neu aufbauen.


Fazit:
Obwohl beide Boards bezüglich der HW in Frage kommen, ist der zusätzliche HW-Aufwand beim DUE zu berücksichtigen. Bei der SW (IDE Compiler- und Library-Fehler) könnte der DUE eher zum Ziel führen, auch weil einige Lib-Entwickler ihre SW DUE-tauglich machen möchten (wann?). Die IDE vom Max32 wird vermutlich nicht "zügig" weiterentwickelt. Ich habe hierzu keine Statments (auch nicht in div. Foren usw.) gefunden und auch nicht von Digilent selbst.

Trotzdem ist es interessant und wichtig die Entwicklung der IDEs dieser Boards "im Auge" zubehalten. Erfahrungen und Tests mit den aktuellen Versionen der jeweiligen IDEs und deren Compiler sind jederzeit möglich:
Arduino DUE (im BetaStatus)
ChipKit Max 32
..
 
Ich schaue derzeit, ob die CPUs von ihrer Architektur vergleichbar sind - Der ChipKit Max32 basiert auf einem PIC32 (Microchip PIC32MX795F512), der Due basiert auf einem ARM Cortex M3 (Atmel SAM3X8E).

Wenn eine einzige, zukünftige CPU alle Aufgaben der bisherigen CPUs (Nanos) und noch mehr erledigen soll, spielt insbesondere die CPU-Architektur eine große Rolle. Beispielsweise sollte es möglich sein, die per ADC gesampelten Signale der Induktionsschleife via DMA direkt in den Speicher zu schreiben (DMA-Fähigkeit), damit die CPU nicht via Polling mit der hohen Frequenz belastet wird. Das sollte bei beiden Architekturen funktionieren, die ARM-Architektur scheint hier aber mehr zu bieten.

PIC32MX795F512
DMA-Kanäle: 8 http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC32MX795F512L
Atmel SAM3X8E
DMA-Kanäle: 17 für Peripherie, 6 allgemein, 1 USB http://www.atmel.com/devices/SAM3X8E.aspx?tab=parameters
Eine weitere wichtige Eigenschaft könnten verschachtelte Interrupts darstellen, so sollte z.B. ein Timer-Interrupt welcher für den Stepper-Motor das Stepper-Rampensignal generiert, höhere Priorität haben als ein Signal-Interrupt für den Modellbau-Receiver. Nested Interrupts beherschen beide Architekturen.

Last but not least sollte man evtl. schauen welche zukünftigen Alternativen es am Markt gibt, wenn man sich für eine Architektur entscheidet. Da gibt es vermutl. mehr Alternativen was ARM angeht.
 
Hallo Alexander,

ja ist alles richtig. Ich favorisiere auch den DUE.
Ich hoffe wir kommen bei beiden CPUs nicht so schnell an eine Grenze, da wir es beim ArdoMower nicht unbedingt mit zeitkritschen Abläufen zu tun haben. Falls doch ein zeitkritisches Ereignis entsteht - Interrupt-Priorisierung ist bei beiden CPUs möglich.

Selbstverständlich gibt es auf dem Markt jede Menge Entwicklungboards die geeignet sind. Möchte man jedoch auf der Arduino- und IDE- Plattform bleiben, sehe ich keine Auswahl. Strebt man bald eine Leiterplatte als Zwischenboard Mega Module an, also weg von der problematischen Handverdrahtung, wird eine Entscheidung zum Basisboard auch notwendig.

Würde man einmal die Aufgaben die heute von den Nanos erledigt wird auf den DUE portieren könnte man sehen ob die 80Mhz CPU das locker oder nur mit Mühe schafft. DMA-Technik einmal aussen vor.

Ich werde das Thema "Umstellung auf den DUE" (ChipKit) nun doch erst einmal zurückstellen.
 
Hallo Rainer,

Rainer_R schrieb:
Ich hoffe wir kommen bei beiden CPUs nicht so schnell an eine Grenze, da wir es beim ArdoMower nicht unbedingt mit zeitkritschen Abläufen zu tun haben.

Gerade deswegen arbeiten wir ja derzeit mit mehreren CPUs :)

zeitkritisch:
-Schleifenfilterung: ADC Sampling: 20 Khz - für spätere Phasendetektion darf kein Sample verloren gehen
-Schritt-Motor Signal-Generierung (Rampe): 3,3 Khz
-Modellbau-Fernbedienung einlesen (PPM 50 Hz), benötigte Genauigkeit des Interrupt:
 
Zuletzt bearbeitet von einem Moderator:
Hallo Alexander,

das vorliegende Konzept ist für die Arduino-Plattform schon sehr anspruchsvoll und evt. auch in Zukunft nur mit mehreren CPUs zu lösen. Aber evt. ergeben sich z.B. bezüglich der Schrittmotoransteuerung oder RC-Fernbedienung (Hardware-) Alternativen die die CPU entlasten können. Das wäre insofern wichtig, da ...

Die Verwendung von mehreren CPUs den Nachbau nicht erleichtern :( .

Eine Reduzierung der Nanos bzw. der Verzicht und nur mit einer CPU zu arbeiten wäre schon ein vernünftiges Ziel.

Aber lassen wir uns Zeit, das Projekt ist ja noch jung.
 
Oben