Vorteile von 32-Bit-Mikroprozessoren mit 48 bis 96 MHz (wie in Arduino Due)


10

Es scheint, dass Arduino Due (32-Bit, 84 MHz, ARM-Cortex-M3-basiertes SAM3X8E) heute veröffentlicht wurde.

Darüber hinaus gibt es in dieser Kategorie eindeutig eine Vielzahl von Prozessoren (32-Bit / 48-96 MHz / ARM) sowie entsprechende Prototyping-Boards:

  • NXP LPC1768 / mBed
  • STM32 / Discovery
  • PIC32 / ChipKit
  • PIC32 / Parallax Propeller
  • LM4F120 / TI Launchpad
  • etc.

Ich versuche, die Attraktivität dieser "Zwischen" -Mikroprozessoren zu verstehen, die mir zwischen dem Low-End-AVR / MSP430 / etc. Zu liegen scheinen. (Profis: kostengünstig, stromsparend, klein) und das High-End-ARM7 / etc (Profis: weitaus mehr Anweisungen pro Sekunde).

In welchen Situationen oder auf welche Weise sind 32-Bit / 48-96 MHz / ARM-basierte Mikroprozessoren eine geeignete Wahl? Insbesondere frage ich mich, in welchen Anwendungen oder in welchen Parametern sie während des Entwurfs eine überlegene Wahl treffen würden, sowohl gegenüber den Low-End-8-Bit-Mikrocontrollern als auch gegenüber den sehr High-End-ARM7-Prozessoren.


Nun, als erstes können Sie Live-Videostreams verarbeiten - wo der Arduino damit nicht umgehen konnte. Es ermöglicht auch erweiterte Verschlüsselungsalgorithmen oder Hashing (schneller und einfacher als in Arduino). Ich bin überrascht, dass das Arduino eine 32-Bit-Plattform herausgebracht hat, aber es zeigt Ihnen nur, dass einige Leute einfach mehr als nur ein Relais steuern möchten. Es ist ein großartiger Tag für Arduino!
Piotr Kula

Sie werden nicht mehr als eine triviale Live-Videoverarbeitung auf einem <100-MHz-Prozessor ausführen, es sei denn, Sie tun dies in einem angeschlossenen Spezialfunktionskern. Und vor allem nicht in dem ziemlich begrenzten On-Board-RAM dieser Geräte. Ein realistischerer Punkt ist, dass die Kosten dieser Chips nicht wesentlich höher sind als die von 8-Bit-Teilen. Es kann tatsächlich niedriger sein als ein ATMEGA mit vergleichbarem Flash & RAM.
Chris Stratton

3
Soweit ich weiß, ist Parallax Propeller ein kundenspezifischer Chip ohne Bezug zu PIC32. Irgendwelche Quellen für die Verbindung?
AndrejaKo

Antworten:


12

Dies ist eines der Themen, über die viel diskutiert werden kann. Es gibt so viele verschiedene Sichtweisen und verschiedene Dinge sind für verschiedene Menschen wichtig. Ich werde versuchen, eine umfassende Antwort zu geben, aber ich verstehe, dass es immer jemanden geben wird, der anderer Meinung ist. Verstehe nur, dass diejenigen, die mit mir nicht einverstanden sind, falsch liegen. (Ich mache nur Spaß.)

Kurze Zusammenfassung:

Diese Antwort wird lang sein, also lassen Sie mich dies vorab zusammenfassen. Für die überwiegende Mehrheit der Menschen bietet die neueste Ernte von ARM Cortex-M0 / M3 / M4-Chips die beste Lösung, die besten Funktionen für die Kosten. Dies gilt sogar, wenn diese 32-Bit-MCUs mit ihren 8- und 16-Bit-Vorfahren wie dem PIC und dem MSP430 verglichen werden. M0s können für weniger als 1 US-Dollar pro Stück und M4 für weniger als 2 US-Dollar pro Stück gekauft werden. Abgesehen von den sehr preisempfindlichen Anwendungen sind die ARM-Lösungen sehr gut. M0s haben eine sehr geringe Leistung und sollten für die meisten Menschen gut genug sein. Für diejenigen, die sehr leistungsempfindlich sind, ist der MSP430 möglicherweise immer noch die bessere Wahl, aber die M0 sind auch für diese Anwendungen eine Überlegung wert.

Wenn Sie an einer eingehenderen Analyse interessiert sind, lesen Sie weiter, andernfalls können Sie jetzt aufhören zu lesen.

Ich werde jetzt jeden Bereich betrachten und die verschiedenen MCUs vergleichen:

Ausführungsgeschwindigkeit

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 Gleitkomma-Unterstützung in Hardware bieten. 8- und 16-Bit-CPUs können mit 32-Bit-Zahlen arbeiten, dies ist jedoch nicht effizient. Dadurch werden schnell CPU-Register, CPU-Taktzyklen und Flash-Speicher für die Programmspeicherung verbraucht.

Einfache Entwicklung

Meiner Meinung nach ist dies der wertvollste Grund für die Verwendung moderner 32-Bit-MCUs - aber auch der am wenigsten geschätzte. Lassen Sie mich dies zunächst mit den 8-Bit-PICs vergleichen. Dies ist der schlechteste Vergleich, aber auch der beste, um meine Punkte zu veranschaulichen.

Die kleineren PICs erfordern grundsätzlich, dass die Programmierung in Assemblersprache erfolgt. Es gibt zwar C-Compiler, die auch für 8-Bit-PICs verfügbar sind, 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 insofern verkrüppelt, als ihre Optimierung nicht so gut ist wie die "Pro" -Version. Die Pro-Version kostet ungefähr 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 ein weiteres Exemplar für weitere 1.000 US-Dollar kaufen. Die "Standard" -Version des Compilers bietet eine mittlere Optimierungsstufe 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 es Einschränkungen gibt, beziehen sich diese Einschränkungen normalerweise auf die maximale Größe des unterstützten Flash-Speichers. Bei den Freescale Codewarrior-Tools beträgt diese Grenze 128 KByte. Dies ist genug für die meisten Leute in diesem Forum.

Der Vorteil der Verwendung eines C-Compilers besteht darin, dass Sie sich nicht (so sehr) mit den Details der Speicherzuordnung der CPU auf niedriger Ebene befassen müssen. Das Paging auf dem PIC ist besonders schmerzhaft und wird am besten vermieden, wenn dies überhaupt möglich ist. Ein weiterer Vorteil ist, dass Sie sich nicht mit dem Durcheinander von 16- und 32-Bit-Nummern auf einer 8-Bit-MCU (oder 32-Bit-Nummern auf einer 16-Bit-MCU) herumschlagen müssen. Während es nicht sehr schwierig ist, dies in Assemblersprache zu tun, ist es ein Schmerz im Heck und fehleranfällig.

Es gibt andere Nicht-ARM C-Compiler, die gut funktionieren. Der MSP430-Compiler scheint einen vernünftigen Job zu machen. Die Cypress PSoC-Tools (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 abgeschreckt, dass ich mir nicht einmal die Mühe gemacht habe, mir ihre neueren Sachen anzusehen. (Haftungsausschluss: Dies bedeutet, dass die neuen PICs möglicherweise verbessert werden 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 Byte sind. Mit einer 16-Bit-MCU, die auf 64 kByte oder kwords erhöht wird. Mit 32-Bit-MCUs bis zu 4 Gigabyte.

Ein guter C-Compiler kann viel davon vor dem Programmierer (auch bekannt als You) 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 Probleme damit haben. Es geht hauptsächlich darum, wie viele Daten Sie (Arrays und Strukturen) im 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 Paketen erhältlich. 6 und 8 Pins! Derzeit befindet sich der kleinste mir bekannte ARM Cortex-M0 in einem QFN-28. Während ein QFN-28 für die meisten klein genug ist, ist er nicht für alle klein genug.

Kosten

Der billigste PIC ist ungefähr ein Drittel des Preises des billigsten ARM Cortex-M0. Aber das sind wirklich 0,32 US-Dollar gegenüber 0,85 US-Dollar. Ja, dieser Preisunterschied ist für einige von Bedeutung. Aber ich gehe davon aus, dass die meisten Leute auf dieser Website sich nicht um diesen kleinen Kostenunterschied kümmern.

Wenn Sie leistungsfähigere MCUs mit dem ARM Cortex-M0 / M3 / M4 vergleichen, wird der ARM Cortex normalerweise "ungefähr gleichmäßig" oder besser. Wenn man die anderen Dinge berücksichtigt (einfache Entwicklung, Compilerkosten usw.), sind die ARMs sehr attraktiv.

Zweite Zusammenfassung

Ich denke, die eigentliche Frage ist: Warum sollten Sie KEINEN ARM Cortex-M0 / M3 / M4 verwenden? Wenn absolute Kosten super wichtig sind. Wenn ein extrem niedriger Stromverbrauch kritisch ist. Wenn die kleinste Packungsgröße benötigt wird. Wenn Geschwindigkeit nicht wichtig ist. Für die überwiegende Mehrheit der Anwendungen gilt jedoch keine dieser Anwendungen, und der ARM ist derzeit die beste Lösung.

Angesichts der geringen 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 Designrändern 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, einschließlich besserer Entwicklungstools und einer schnelleren Innovation der Technologie.

Natürlich können und müssen sich die Dinge ändern. Was ich sage, ist heute gültig, aber möglicherweise in einem Jahr oder sogar einem Monat nicht mehr gültig. Mach deine eigenen Hausaufgaben.


1
Um mit dem ARM auf einen Speicherort zuzugreifen, muss zuerst ein Register mit einer Adresse geladen werden, die innerhalb von 4 KB liegt. Vielen E / A-Geräten wird mehr als 4 KB Adressraum zugewiesen, obwohl viele nur wenige diskrete Adressen verwenden. Im Gegensatz dazu können die 18Fxx-PICs unabhängig vom Bankstatus direkt an den meisten E / A-Standorten mit einem einzigen Befehl betrieben werden. Die Art und Weise, wie der größte Teil des Arbeitsspeichers in einem Bank gespeichert wird, ist ziemlich ärgerlich, aber für bestimmte Arten von Bit-Banging (der Zweck, für den die PIC-Architektur in den 1970er Jahren entworfen wurde) funktioniert die PIC-Architektur sehr gut.
Supercat

1
Übrigens finde ich es merkwürdig, dass ein beliebter 8-Bit-Mikroprozessor aus den 1970er Jahren willkürlich ausgerichtete 256-Byte-Datenstrukturen effizient verarbeiten konnte und ein beliebter 16-Bit-Prozessor gut mit 65.536-Byte-Datenstrukturen zusammenarbeiten konnte, die auf 16 ausgerichtet waren -Byte-Grenzen oder willkürlich ausgerichtete Datenstrukturen, fast so große, neuere 8-Bit- und 16-Bit-Prozessoren, machen es schwierig, effizienten Code zu schreiben, der sich über Seiten- / Bankgrenzen erstreckt.
Supercat

@supercat Der 4K-Adressbereich für eine Anweisung "LDR / SRT Immediate Offset" ist wahr, aber häufig kein Problem. Ich bin mit dem Rest Ihres Kommentars nicht einverstanden. In den Freescale M4-Dokumenten nimmt jedes Peripheriegerät nicht mehr als 4 KB Adressbereich ein, sodass ein einziger "Basisadresszeiger" für den Zugriff auf alle Register in diesem Peripheriegerät ausreicht. Es gibt auch 32 Allzweckregister, von denen jedes als Basisadresszeiger verwendet werden kann. Der schnelle Zugriff auf mehrere Peripheriegeräte im selben Codeabschnitt ist daher relativ problemlos.

1
@supercat Ihr zweiter Punkt berührt die gesamte Debatte zwischen RISC und CISC. ARM ist eine RISC-CPU, was bedeutet, dass sie für die häufigsten Aufgaben optimiert ist. Nicht häufige Aufgaben wie nicht ausgerichtete Zugriffe erfordern entweder mehr Arbeit oder mehr Zeit (abhängig vom CPU-Bogen). Ich betrachte dies als eine positive Sache, nicht als eine negative Sache. Deshalb bekommen wir schnelle 32-Bit-MCUs zum Preis eines älteren 8-Bit. Selbst mit diesen Macken würde ich jeden Tag eine dieser CPUs über einen PIC bringen.

Ich habe falsch geschrieben; Ich wollte nicht implizieren, dass ein Basisregister nicht ein ganzes Peripheriegerät verarbeiten kann, sondern dass häufig ein Register für jedes Peripheriegerät geladen werden muss (man kann also nicht einfach z. B. ein Register die ganze Zeit mit IO_BASE_ADDR sitzen lassen ). Bei einigen Codetypen kann es sehr praktisch sein, ein E / A-Bit in einem einzelnen Zyklus mit einem Befehl wie "bsf LATA, 4" zu setzen, ohne vorher Register vorladen zu müssen. Ich mag den ARM, aber die direkte E / A-Zuordnung auf dem PIC kann sehr gut sein (schade, dass anderer Speicherzugriff nicht so gut ist).
Supercat

3

David Kessner ist richtig. Ich möchte Folgendes hinzufügen.

  1. 8-Bit-MCUs sind die einzigen MCUs, die in PDIP-Paketen verfügbar sind, die einfach zu handhaben und einfach in ein Prototyping-Steckbrett zu stecken sind.
  2. 32-Bit-MCUs können tatsächlich weniger Strom verbrauchen als 8-Bit-MCUs. Es ist nicht unbedingt richtig, dass die 8-Bit-MCU mit <20 MHz weniger Strom verbraucht als ein Cortex M4.
  3. 8-Bit-MCUs werden häufig von Hobbyisten verwendet, die normalerweise nicht viel von der MCU benötigen. Vielleicht ein paar hundert Zeilen einfachen C-Codes.

Ich bin damit einverstanden, dass es heutzutage kaum einen Grund gibt, keine 32-Bit-MCUs zu verwenden. Ich würde sie [8-Bit-MCUs] nur aus zwei Gründen verwenden: Ich mag die Leichtigkeit des PDIP-Pakets (kein Löten erforderlich); Ich brauche oft nicht mehr Leistung / Komplexität als eine 8-Bit-MCU bieten kann.

Der Deal Breaker ist wirklich das verfügbare Werkzeug.


Für das Prototyping gibt es Sockel für LQFP, die ziemlich gut funktionieren. Und natürlich Sie können LQFP von Hand gelötet werden , dauert nur ein bisschen Übung. QFN, DFN und BGA Ich würde nicht von Hand löten, aber dann kommt jede einzelne 32-Bit-Low-End-MCU auf dem Markt mit LQFP.
Lundin

1

Wir verwenden einen relativ unmodernen Freescale MCF52259, eine 32-Bit-MCU mit ~ 80 MHz.

Gründe / Denkprozess für die Wahl waren:

  • Es ersetzte ein 32-Bit-M.Core-Gerät, sodass die Portierung relativ einfach war
  • Es bedeutete auch, dass wir bei der bestehenden IDE (CodeWarrior) bleiben konnten.
  • Wir brauchten viel IO: Steuerung für Schritt / Richtung bei 3 Schrittmotoren, 4 PWM-Kanälen, 3 UARTs sowie I2C und SPI.
  • Es war viel los (siehe letzter Punkt) und einiges davon musste rechtzeitig geschehen, also mussten wir sicherstellen, dass es genügend CPU-Zyklen gab, um alles zu erledigen.
  • Der Legacy-Code stieß auf die 256-KB-Flash-Größe und den 32-KB-RAM des M.Core, sodass die Verdoppelung des Flashs und des Arbeitsspeichers das schnelle Einrichten und Ausführen des Lebens erleichterte.

Heutzutage ist es kostengünstiger (und zweckmäßiger), die Funktionen der Hardware (Speicher, Geschwindigkeit, E / A usw.) zu überspezifizieren / zu erweitern, als wertvolle Entwicklungszeit damit zu verbringen, den Code zu optimieren, um ihn in eine geringfügig billigere / kleinere MCU zu integrieren, sofern nicht genügend Speicherplatz vorhanden ist Macht sind große Probleme.

In unserem Fall war das Gerät doppelt so hoch wie die Spezifikation des M.Core zum halben Preis. Wenn Sie zu einer günstigeren MCU wechseln, sparen Sie nur ein paar Cent pro Board, kosten jedoch viel Entwicklungszeit und begrenzen das Potenzial für zukünftige Entwicklungen, ohne die MCUs erneut zu ändern.

Wenn wir eine Million Boards bauen würden, wäre es die Kosten-Engineering-Übung wert, die Dinge zu reduzieren, aber so wie es aussieht, ist es die Entwicklungszeit nicht wert.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.