Es scheint, dass Arduino Due (32-Bit, 84 MHz, ARM-Cortex-M3-basierter SAM3X8E) heute veröffentlicht wurde.
Darüber hinaus gibt es in dieser Kategorie offensichtlich eine Vielzahl von Prozessoren ( 32-Bit / 48-96 Mhz / ARM ) sowie entsprechende Prototyping-Boards:
Ich versuche, die Anziehungskraft dieser "Zwischen" -Mikroprozessoren zu verstehen, die meiner Meinung nach zwischen den Low-End-AVR / MSP430 / etc. liegen. (Vorteile: preiswert, geringer Stromverbrauch, geringer Platzbedarf) und das High-End-ARM7 / etc (Vorteil: weitaus größere Anweisungen pro Sekunde).
In welchen Situationen oder Wegen sind 32-Bit / 48-96 MHz / ARM-basierte Mikroprozessoren eine geeignete Wahl? Genauer gesagt frage ich mich, in welchen Anwendungen oder in welchen Parametern sie während des Designs eine bessere Wahl treffen würden, sowohl gegenüber den Low-End-8-Bit-Mikrocontrollern als auch gegenüber den High-End-ARM7-Prozessoren.
Dies ist eines der Themen, die heftig diskutiert werden können. Es gibt so viele verschiedene Sichtweisen, und verschiedene Dinge sind für verschiedene Menschen wichtig. Ich werde versuchen, eine umfassende Antwort zu geben, aber verstehe, dass es immer jemanden geben wird, der anderer Meinung ist. Verstehen Sie einfach, dass diejenigen, die nicht meiner Meinung sind, Unrecht haben. (War nur Spaß.)
Kurze Zusammenfassung:
Diese Antwort wird lang werden, also lassen Sie mich das vorweg zusammenfassen. Für die überwiegende Mehrheit der Menschen bietet die neueste Generation von ARM Cortex-M0/M3/M4-Chips die beste Lösung, die besten Funktionen für die Kosten. Dies gilt sogar, wenn man diese 32-Bit-MCUs mit ihren 8- und 16-Bit-Vorfahren wie den PIC und MSP430 vergleicht. M0s können für weniger als 1 US-Dollar pro Stück und M4s für weniger als 2 US-Dollar pro Stück gekauft werden. Abgesehen von den sehr preisempfindlichen Anwendungen sind die ARM-Lösungen also sehr gut. M0 sind sehr leistungsschwach und sollten für die meisten Menschen gut genug sein. Für diejenigen, die sehr leistungsempfindlich sind, könnten die MSP430 immer noch eine bessere Wahl sein, aber die M0s sind auch für diese Anwendungen eine Überlegung wert.
Wenn Sie an einer tiefergehenden Analyse interessiert sind, lesen Sie weiter, ansonsten können Sie jetzt aufhören zu lesen.
Ich werde mir nun jeden Bereich ansehen und die verschiedenen MCUs vergleichen:
Geschwindigkeit der Ausführung
Natürlich werden die 32-Bit-MCUs schneller sein. Sie haben tendenziell eine schnellere Taktrate, erledigen aber auch mehr Arbeit für jede dieser Uhren. MCUs wie der ARM Cortex-M4 enthalten DSP-Verarbeitungsanweisungen und können sogar Fließkommaunterstützung in der Hardware haben. 8- und 16-Bit-CPUs können mit 32-Bit-Zahlen arbeiten, aber das ist nicht effizient. Dadurch werden schnell CPU-Register, CPU-Taktzyklen und Flash-Speicher für die Programmspeicherung verbraucht.
Leichtigkeit der Entwicklung
Meiner Meinung nach ist dies der wertvollste Grund für die Verwendung moderner 32-Bit-MCUs – aber auch der am meisten unterschätzte. Lassen Sie mich dies zunächst mit den 8-Bit-PICs vergleichen. Dies ist der Worst-Case-Vergleich, aber auch der beste, um meine Punkte zu veranschaulichen.
Die kleineren PICs erfordern grundsätzlich, dass die Programmierung in Assemblersprache erfolgt. Es stimmt, es gibt sogar C-Compiler für die 8-Bit-PICs, aber diese Compiler sind entweder kostenlos oder gut. Sie können keinen Compiler bekommen, der sowohl gut als auch kostenlos ist. Die kostenlose Version des Compilers ist dahingehend gelähmt, dass seine Optimierung nicht so gut ist wie die "Pro"-Version. Die Pro-Version kostet etwa 1.000 US-Dollar und unterstützt nur eine Familie von PIC-Chips (8-, 16- oder 32-Bit-Chips). Wenn Sie mehr als eine Familie verwenden möchten, müssen Sie eine weitere Kopie für weitere 1.000 US-Dollar kaufen. Die "Standard"-Version des Compilers bietet ein mittleres Optimierungsniveau und kostet etwa 500 US-Dollar für jede Chipfamilie. Die 8-Bit-PICs sind nach modernen Standards langsam und erfordern eine gute Optimierung.
Im Vergleich dazu gibt es viele gute C-Compiler für ARM-MCUs, die kostenlos sind. Wenn Einschränkungen bestehen, beziehen sich diese normalerweise auf die maximale Größe des unterstützten Flash-Speichers. Bei den Freescale Codewarrior-Tools beträgt diese Grenze 128 KB. Das reicht den meisten hier im Forum.
Der Vorteil der Verwendung eines C-Compilers besteht darin, dass Sie sich nicht (so sehr) mit den Low-Level-Details der Speicherzuordnung der CPU beschäftigen müssen. Paging auf dem PIC ist besonders schmerzhaft und sollte möglichst vermieden werden. Ein weiterer Vorteil ist, dass Sie sich nicht mit dem Durcheinander herumschlagen müssen, 16- und 32-Bit-Zahlen auf einer 8-Bit-MCU (oder 32-Bit-Zahlen auf einer 16-Bit-MCU) zu übergeben. Während es nicht besonders schwierig ist, dies in Assemblersprache zu tun, ist es ein Schmerz im Hintern und fehleranfällig.
Es gibt andere Nicht-ARM-C-Compiler, die gut funktionieren. Der MSP430-Compiler scheint einen vernünftigen Job zu machen. Die PSoC-Tools von Cypress (insbesondere PSoC1) sind fehlerhaft.
Flaches Speichermodell
Eine MCU, die RAM/Register/Flash ausgelagert hat, ist einfach dumm. Ja, ich spreche von den 8-Bit-PICs. Dumm, dumm, dumm. Das hat mich so sehr von den PICs abgebracht, dass ich mir nicht einmal die Mühe gemacht habe, mir ihre neueren Sachen anzusehen. (Haftungsausschluss: Das bedeutet, dass die neuen PICs verbessert werden könnten und ich weiß es einfach nicht.)
Mit einer 8-Bit-MCU ist es schwierig (aber nicht unmöglich), auf Datenstrukturen zuzugreifen, die größer als 256 Bytes sind. Mit einer 16-Bit-MCU wird das auf 64 kByte oder kWorte erhöht. Bei 32-Bit-MCUs geht das bis zu 4 Gigabyte.
Ein guter C-Compiler kann vieles davon vor dem Programmierer (auch bekannt als Sie) verbergen, aber selbst dann wirkt sich dies auf die Programmgröße und die Ausführungsgeschwindigkeit aus.
Es gibt viele MCU-Anwendungen, für die dies kein Problem darstellt, aber natürlich gibt es viele andere, die damit Probleme haben werden. Es ist hauptsächlich eine Frage, wie viele Daten Sie (Arrays und Strukturen) in RAM oder Flash benötigen. Mit zunehmender CPU-Geschwindigkeit steigt natürlich auch die Wahrscheinlichkeit, größere Datenstrukturen zu verwenden!
Packungsgrösse
Einige der kleinen PICs und andere 8-Bit-MCUs sind in wirklich kleinen Gehäusen erhältlich. 6 und 8 Stifte! Derzeit befindet sich der kleinste ARM Cortex-M0, den ich kenne, in einem QFN-28. Während ein QFN-28 für die meisten klein genug ist, ist es nicht klein genug für alle.
Kosten
Der günstigste PIC kostet etwa ein Drittel des günstigsten ARM Cortex-M0. Aber das sind wirklich 0,32 US-Dollar gegenüber 0,85 US-Dollar. Ja, dieser Preisunterschied spielt für einige eine Rolle. Aber ich gehe davon aus, dass die meisten Leute auf dieser Website sich nicht um diesen kleinen Kostenunterschied kümmern.
Auch beim Vergleich leistungsfähigerer MCUs mit dem ARM Cortex-M0/M3/M4 schneidet der ARM Cortex in der Regel „ungefähr gleich“ oder an der Spitze ab. Wenn man die anderen Dinge berücksichtigt (einfache Entwicklung, Compilerkosten usw.), dann sind die ARMs sehr attraktiv.
Zweite Zusammenfassung
Ich denke, die eigentliche Frage ist: Warum würden Sie KEINEN ARM Cortex-M0/M3/M4 verwenden? Wenn die absoluten Kosten super wichtig sind. Wenn ein extrem niedriger Stromverbrauch entscheidend ist. Wenn die kleinste Verpackungsgröße benötigt wird. Wenn es nicht auf Geschwindigkeit ankommt. Aber für die überwiegende Mehrheit der Anwendungen trifft nichts davon zu und der ARM ist derzeit die beste Lösung.
Angesichts der niedrigen Kosten ist es sinnvoll, einen ARM Cortex zu verwenden, es sei denn, es gibt einen guten Grund, keinen ARM Cortex zu verwenden. Es ermöglicht eine schnellere und einfachere Entwicklungszeit mit weniger Kopfschmerzen und größeren Designspielräumen als die meisten anderen MCUs.
Es gibt andere Nicht-ARM-Cortex-32-Bit-MCUs, aber ich sehe auch keinen Vorteil für sie. Die Verwendung einer Standard-CPU-Architektur bietet viele Vorteile, darunter bessere Entwicklungstools und eine schnellere Innovation der Technologie.
Natürlich können und werden sich die Dinge ändern. Was ich sage, ist heute gültig, aber vielleicht in einem Jahr oder sogar einem Monat von jetzt an nicht mehr gültig. Machen Sie Ihre eigenen Hausaufgaben.
David Kessner hat Recht. Folgendes möchte ich hinzufügen.
Ich stimme zu, dass es heutzutage wenig Grund gibt, keine 32-Bit-MCUs zu verwenden. Ich würde sie [8-Bit-MCUs] nur aus zwei Gründen verwenden: Ich mag die Einfachheit des PDIP-Gehäuses (kein Löten erforderlich); Ich brauche oft nicht mehr Leistung/Komplexität als das, was eine 8-Bit-MCU bieten kann.
Der Deal Breaker sind wirklich die verfügbaren Tools.
Wir verwenden einen relativ unmodernen Freescale MCF52259, eine 32-Bit-~80-MHz-fähige MCU.
Gründe/Überlegungen für die Wahl waren:
Heutzutage ist es kostengünstiger (und zweckdienlicher), die Fähigkeiten der Hardware (Speicher, Geschwindigkeit, E/A usw.) zu spezifizieren / zu erweitern, als wertvolle Entwicklungszeit damit zu verbringen, den Code zu optimieren, um ihn in eine geringfügig billigere/kleinere MCU zu quetschen, es sei denn, es ist Platz oder Macht sind große Themen.
In unserem Fall hatte das Gerät die doppelte Spezifikation des M.Core zum halben Preis. Der Wechsel zu einer billigeren MCU würde nur ein paar Cent pro Platine sparen, aber viel Entwicklungszeit kosten und das Potenzial für zukünftige Entwicklungen einschränken, ohne die MCUs erneut zu wechseln.
Wenn wir eine Million Boards bauen würden, würde es sich lohnen, die Kosten-Engineering-Übung durchzuführen, um die Dinge zu reduzieren, aber so wie es aussieht, ist es die Entwicklungszeit nicht wert.
Piotr Kula
Chris Stratton
Andreja Ko