Mikrocontroller Vergleich
Ein paar Kriterien für den CPU-Core und die µC-Familie.
Compiler verfügbar, bzw wieviel will man dafür ausgeben?
Und wie verbreitet ist der Compiler? Finde ich dafür Hilfe, beispielsweise in Form von Support-Foren?
Für ARM, AVR und MSP430 gibt es mit GCC einen guten und kostenlosen Compiler. Bei ARM ist sind jedoch die Schritte zum fertigen Programm recht komplex und Library/Laufzeitsystem benötigen einige Handarbeit. Für ARM gibt es von IAR eine auf 32KB begrenzte kostenlose Version eines umgänglicheren kommerziellen Compilers.
Für PIC und 8051 kann man entweder SDCC verwenden (über dessen Qualität mögen andere urteilen, ich kenne ihn nicht). Oder diverse Löhnwares, bis 4-stellige Beträge (Keil: 2600€), teils auch als Demoversion mit Tricks.
Bei PIC sind das der PICC Lite von HI-TECH, der nur eine handvoll PIC12 und PIC16 unterstützt, und der CC5X, welcher zwar keine High-End PICs unterstützt, dafür die meisten Mid-Range; einzige Einschränkung der freien Version des CC5X ist die Limitierung auf 1024 Instruktionen pro Modul, nicht so gute Codeoptimierung und die Begrenzung von Variablen auf 16-Bit. Ein Vergleich aller C-Compiler für PIC findet sich hier: http://www.informel.de/pic/ccompiler.htm
Bei Zilog Z8e sind IDE und C-Compiler Bestandteil recht günstiger Development Kits.
Architektur
Betrifft vor allem Assembler-Programmierung und die Frage, wie einfach oder umständlich sich C-Code in Maschinensprache übersetzen lässt.
Dass für alle Architekturen teils mehrere C-Compiler existieren, hat wenig mit Eignung und viel mit Markt zu tun. Zudem ist meist nur entscheidend, ob ein Controller die Anforderungen erfüllt, nicht jedoch wie gut er das tut.
Manches davon ist durchaus subjektiv. Bei abweichender Meinung bitte als Diskussion starten, nicht einfach löschen.
8051: Typische Akkumulator-orientierte 8-Bit Architektur. Eine gewisse Komplexität entstand durch die sukzessive Erweiterung auf mehr RAM als ursprünglich vorgesehen war, mit etlichen unterschiedlich adressierten RAM-Bereichen als Folge. Für C-Compiler nur eingeschränkt geeignet.
ARM: 32bit RISC-Architektur. In den gängigen Implementierungen stehen 2 Befehlssätze zur Verfügung: 32bit-codiert für Tempo und 16bit-codiert (Thumb) für kompakte Programme. Einheitlicher 32bit Adressraum. Exzellente Zielmaschine für C-Compiler.
AVR: Register-orientierte, an RISC Prinzipien angelehnte 8-Bit Architektur. Getrennte Adressräume für RAM und ROM. Registersatz nicht einheitlich nutzbar. I/O-Bereich nicht einheitlich adressierbar. Nur ein Teil des I/O-Bereiches ist bitweise manipulierbar. Einheitliche RAM-Adressierung. Für C-Compiler geeignet.
MSP430: Register-orientierte 16-Bit Architektur. 2-Adress-CISC. Einheitlicher Adressraum für RAM und ROM. Exzellente Zielmaschine für C-Compiler. Angelehnt an die legendäre PDP-11, vieles wurde übernommen.
PIC: Akkumulator-orientierte 8-Bit Architektur. Getrennte Adressräume für RAM und ROM. RAM-Banking, ROM-banking. Umständlicher Zugriff auf Daten im ROM (nur 12/14-Bit Versionen). Viele für C-Compiler wesentliche Elemente sind nur umständlich realisierbar (z.B. Code/Datenadressierung mit Banking, Vergleich mit Vorzeichen).
Z8e: Register-orientierte 8-Bit Architektur, 2-Adress-CISC. Getrennte Adressräume für RAM und ROM. Historisch bedingt 3 RAM-Adressräume (8-Bit, 12-Bit, 16-Bit). Für C-Compiler geeignet
Sind CPU-spezifische Erweiterungen in C erforderlich
8051:
- 5-6 Speicherklassen für Datenspeicher (direkt, indirekt, 8-Bit "external", 16-Bit "external", Flash, evtl. noch Einzelbits).
AVR:
- 2 Speicherklassen für Datenspeicher (RAM, ROM).
ARM, MSP430: nein.
PIC:
- 3 Speicherklassen für Datenspeicher (shared RAM, banked RAM, ROM).
Z8e:
- Für atomic execution (s.u.) notwendig, aber nicht existent.
- 4 Speicherklassen für Datenspeicher (256B, 4KB, 64KB, Flash).
Sind Daten in RAM und ROM mit dem gleichen Code benutzbar
8051, AVR, PIC, Z8e wie generell alle Harvard-Architekturen: NEIN. Daten im ROM erfordern anderen Zugriff als Daten im RAM. Entweder versteckt das der Compiler in Runtime-Routinen für Pointerzugriffe, oder man kann Routinen nicht so schreiben, dass sie beides als Parameter verdauen können. Bei kleinen Programmen von ein paar KB kein Problem, bei grösseren jedoch schon. Bei AVR/GCC ziemlich fehlerträchtig.
MSP430: von Neumann-Architektur, problemlos.
Lineare Adressierung vom RAM?
8051, AVR, MSP430, Z8e: kein Problem.
PIC: 16-bit PIC ja, 14-, 12-bit PIC nein. RAM-Puffer die grösser sind als das RAM in einer Bank sind nur mit Klimmzügen möglich.
Skalierbarkeit
Vor allem für jene wichtig, die sich scheuen, für verschiedene Aufgaben verschiedene Lösungen zu verwenden.
Spezielle Versionen für LCD-Ansteuerung wurden in dieser Übersicht nicht berücksichtigt.
8051: 20-Pin/2KB aufwärts, überwiegend 40/44-Pin und 64/68-Pin. Architekturbedingte Grenze bei 64KB Code, 64KB RAM - Versionen mit mehr Flash nutzbar via Banking (Compiler-Support vorhanden) existieren, Versionen mit bis zu 100 MHz Taktfrequenz verfügbar.
AVR: 8-Pin/1KB bis 64-Pin/128KB, 100-Pin/256KB in Vorbereitung. Architekturbedingte Grenze bei 8MB Code, 64KB RAM. GCC/WinAVR derzeit nur bis 128KB Code möglich (in Arbeit).
MSP430: 20-Pin/1KB bis 64-Pin/60KB (in der Roadmap wurden jedoch schon 128KB angekündigt). Architekturbedingte Grenze von 64KB für Code+Daten. Taktfrequenz: 32768 Hz bis maximal 8 bis 16 MHz je nach Familie. Stromaufnahme: Rund 2 uA im LPM3 (real time clock mode) bis ca. 5 mA.
PIC: 6-Pin/512B aufwärts. Im Prinzip grosser Bereich, aber innerhalb der Familie deutlich verschiedene inkompatible Architekturen mit unterschiedlichen architekturbedingen Grenzen und unterschiedlichem Compiler-Support.
Z8e: Bis 64KB Flash. Architekturbedingte Grenze bei 64KB Code, 64KB RAM.
Empfehlung hier: Auch wenn teilweise mehr möglich ist, ist diese Klasse dennoch nur bis maximal 40-60K empfehlenswert. Darüber sollte eine 32-Bit Architektur - z.B. mit ARM-Core - in Betracht gezogen werden. Insbesondere auch, weil grosse Programme zu Programm- und Datenstrukturen neigen, die sich auf 8-Bit Prozessoren schlecht abbilden lassen.
Interrupt-feste Programmierung von I/O-Ports
Das ist besonders bei AVRs (außer den Typen seit 2004: ATtiny2313 usw.) ein Problem. Architekturbedingt ist nur ein Teil der Ports bitweise schaltbar, kein Port kann mehrere Bits gleichzeitig interrupt-fest schalten. Daher ist es eigentlich oft (dann wenn die betreffenden Register in Interrupt-Routinen und im Hauptprogramm verändert werden) nötig, um Port-I/O herum Port-ändernde Interrupts abzuschalten, was aber kaum jemand macht. Folge: ab und zu "seltsames Verhalten", nicht reproduzierbar. Besonders gefährlich bei Software-Baukasten-Prinzip, wenn da manche Selbstverständlichkeiten eines Moduls plötzlich nicht mehr so selbstverständlich sind.
PIC, 8051, MSP430, Z8e können AND/OR/XOR zum Port hin, daher im Prinzip kein Problem - daran denken muss man aber trotzdem (auch das kommt wohl eher selten vor).
Beispiel:
port |= 0x03;
übersetzt sich in
IN r,port
ORI r,0x03
OUT port,r
Wenn nun zwischen IN und OUT ein Interrupt auftritt, der ein anderes Bit des Ports verändert, dann geht mit dem OUT-Befehl diese Änderung verloren.
Bei MSP430 hingegen ist das ein einziger Befehl, somit problemlos:
OR #0x03,port
Code wie
port = (port & ~0x0F) | lcd_data;
ist grundsätzlich problematisch, weil das auf jedem Prozessor in mehrere Befehle zerlegt wird. Bei den AVR Typen seit 2004 lässt sich das ohne Abschaltung von Interrupts beispielsweise durch Verwendung der Pin-Toogle-Funktion lösen:
PINA = (PORTA & 0x0F) ^ lcd_data;
Besonders pfiffig ist das beim Z8e gelöst. Ein Befehl fasst die nächsten 3 Befehle zu einer nicht unterbrechbaren Einheit zusammen (atomic execution). Allerdings wird das vom Zilog Compiler nicht unterstützt.
Zugriff auf I/O-Ports
Der 8051 verfügt weder über eigene Register für die Steuerung der Richtung der I/O-Ports, noch über die Möglichkeit, lesend auf den Sollzustand der Ausgänge zuzugreifen. In Assembler ist das kein Problem, da abhängig vom Befehl entweder vom Zustand der Pins (Leseoperationen) oder vom Sollzustand der Ausgänge (kombinierte Lese/Schreiboperationen) ausgegangen wird. Ein korrekt arbeitender C Compiler kann damit jedoch nicht umgehen, weshalb für die Steuerung von Port-Pins spezielle Zugriffsfunktionen und eine sehr genaue Kenntnis der Arbeitsweise der Ports erforderlich sind.
Anmerkung zum Keil 8051-Compiler: Port-Zugriff erfolgt über Pseudo-Variablen wie bei µC üblich. Infolgedessen ist in C Code nicht ersichtlich, ob beispielsweise die Port-Variable P1 für den Zustand der Pins oder den Sollzustand der Ausgänge steht. Nur der erzeugte Assembler-Code kann hier Klarheit schaffen. So haben die beiden prinzipiell identischen Zeilen
P1 = P1 | 0x01; P1 = (P1 | 0x01) & ~0;
völlig unterschiedliche Auswirkung auf den Port. Der Code der ersten Zeile setzt Bit 0 und lässt alle anderen Bits unverändert. Der von der zweiten Zeile erzeugte Code setzt zusätzlich auch alle vorher als Eingang definierten Pins im Zustand 0 auf Ausgang mit Zustand 0. Das ist weder hilfreich, noch mit der Sprachdefinition von C vereinbar.
Auch manche Modelle der PIC-Familie können nur auf den Zustand der Pins zugreifen, nicht auf den Sollzustand der Ausgänge.
In beiden Fällen ist folglich bei Ports, die sowohl für Aus- als auch für Eingänge benutzt werden, besondere Sorgfalt nötig.
AVR, Z8e und neuere Modelle der PIC-Familie besitzen diese Probleme nicht.
Priorisierte Interrupts
8051: Ja.
AVR: Nein, aber separate Vektoren. Beim Sprung in die Interruptroutine wird implizit ein CLI ausgeführt, beim Rücksprung ein SEI. Ein "unwichtiger Interrupt" blockiert also evtl. einen "wichtigen". Immerhin haben Interruptquellen im Gegensatz zum PIC ihre eigenen Interruptvektoren, so daß keine Zeit mit der Suche nach der Quelle verbracht wird. Um trotzdem für eine von mehreren Interruptquellen eine Reaktionszeiten im unteren Mikrosekundenbereich zu garantieren, hilft nur ein Trick: die weniger wichtigen Interruptroutinen tun nichts als eine Programmadresse auf den Stack zu PUSHen. Das RETI springt also zu dieser Adresse mit der eigentlichen Interruptbehandlung, das RET am Ende der Routine springt zur ursprünglichen Unterbruchstelle zurück; der zeitkritische Interrupt kann damit die andere Interruptbehandlung unterbrechen. Achtung: es muß gewährleistet sein, daß auch im worst case ein Interrupt sich nicht selbst unterbricht!
Anmerkung: Eine (unwichtige) Interruptroutine kann sofort nach Ansprung ein SEI ausführen, damit eine (unwichtige) Interruptroutine jederzeit von einer anderen (wichtigeren) Interruptroutine unterbrochen werden kann. Das kann pro Interruptvektor individuell entschieden werden. Dies ist jedoch nicht bei allen Interrupt-Quellen möglich (beispielsweise nicht beim TWI).
MSP430: Nein, aber separate Vektoren.
PIC12 & PIC16: Nein, nur ein Interruptvektor.
PIC18: Jeder Interruptquelle kann separat eine niedrige oder hohe Priorität zugewiesen werden, die dann auf zwei Interruptvektoren verzweigen. Welche Quelle den Interrupt ausgelöst hat, muß aber immer noch händisch festgestellt werden.
PIC17: Vier Interruptvektoren mit unterschiedlicher Priorität. Scheint es allerdings nur als OTP zu geben, deswegen wohl eher uninteressant.
Z8e: Ja.
I/O-Spannung
8051, AVR, PIC: 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?).
MSP430: nur 1.8-3.6V. Nicht 5V-kompatibel, 5V-Peripherie für I2C/RS485/CAN/... ist also nur mit Pegelkonvertierung einsetzbar.
Z8e: 3V-Core, 5V-kompatibel.
Debugging in der Schaltung
Ist beispielsweise ein günstiges JTAG-Interface für In-Circuit Debugging verfügbar?
8051: Derivate mit JTAG verfügbar. ICEen gebraucht erschwinglich.
AVR: bei ATmegas mit 16 KB und mehr Flash (Ausnahme: ATmega103 und ATmega168) JTAG günstig verfügbar [Olimex, Erostech] oder einfach zu bauen [Evertool]. Neue ATtinys und MegaX8 per debugWIRE, arg teuer.
MSP430: alle mit JTAG, Adapter sehr günstig/einfach zu bauen
PIC: Entweder Microchips MPLAB ICD2 (€150-200) oder ein kompatibler Nachbau, wie z.B. http://www.stolz.de.be/
Z8e: Debugging möglich mit "Smart Cable" (kein JTAG), Anschluss über USB oder Seriell
Starterkits
8051:
AVR: STK200, STK500, AVR_Butterfly, SiSy AVR Starterkit
MSP430:
PIC:
Z8e: Günstig verfügbar [~50€], teils hier im Shop, komplett inklusive unbeschränktem Compiler und In-System-Debugging. Nachteile: für jede Prozessorklasse ein eigenes Kit; eingelöteter SMD-Chip obwohl viele Typen auch im DIL-Gehäuse existieren.
Gehäuse
Mit DIP oder PLCC bastelt es sich leichter als mit *QFP. Die Domäne von AVR/PIC/i51. Z8e-Chips existieren ebenfalls in DIP, sind aber schlechter verfügbar.