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 AVR und MSP430 gibt es mit GCC einen guten und kostenlosen Compiler.
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, 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 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.
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).
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.
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.
Z8e: Register-orientierte 8-Bit Architektur, 2-Adress-CISC. Getrennte Adressräume für RAM und ROM. Historisch bedingt 2 RAM-Adressräume (8-Bit, 12-Bit). 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.
Sind CPU-spezifische Erweiterungen in C erforderlich
8051:
- 5-6 Speicherklassen für die diversen RAM-Varianten.
- Zugriff auf I/O-Ports erfordert spezielle Zugriffsfunktionen.
AVR:
- Für die RAM/ROM-Problematik (s.u.).
PIC:
- Für die RAM/ROM-Problematik (s.u.).
MSP430: nein.
Z8e:
- Für atomic execution (s.u.) notwendig, aber nicht existent.
- 3 Speicherklassen für RAM/ROM.
Sind Daten in RAM und ROM mit dem gleichen Code benutzbar
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: saubere von Neumann-Architektur. Problemlos.
Lineare Adressierung vom RAM?
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.
8051, AVR, MSP430, Z8 kein Problem.
Skalierbarkeit?
Vor allem für jene wichtig, die sich scheuen, für verschiedene Aufgaben verschiedene Lösungen zu verwenden.
- AVR: 8-Pin/1KB bis 64pin/128KB, Tendenz steigend.
- PIC: Im Prinzip grosser Bereich, aber innerhalb der Familie deutlich verschiedene inkompatible Architekturen mit sehr unterschiedlichem Compiler-Support.
- 8051: Von klein bis ganz groß (aber jenseits von 64K wird's hässlich).
- MSP430: RAM+ROM max. 64KB, d.h. bei 60KB Code ist Schluss.
- Z8e: Bis 64KB Flash.
Empfehlung hier: Auch wenn teilweise mehr möglich ist, ist diese Klasse dennoch nur bis 40-60K empfehlenswert. Darüber sollte eine 32-Bit Architektur - z.B. mit ARM-Core - in Betracht gezogen werden.
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.
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 C Compiler kann damit jedoch nicht umgehen, weshalb für die Steuerung von Port-Pins sowohl CPU-spezifische Operationen als auch eine sehr genaue Kenntnis der Arbeitsweise der Ports erforderlich sind.
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
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.
AVR: Nein: 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).
8051, Z8e: ja.
I/O-Spannung
AVR, PIC, 8051: 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?).
Z8e: 3V-Core, 5V-kompatibel.
MSP430: nur 1.8-3.6V. Nicht 5V-kompatibel, 5V-Peripherie für I2C/RS485/CAN/... ist also nur mit Pegelkonvertierung einsetzbar.
Debugging in der Schaltung
Ist beispielsweise ein günstiges JTAG-Interface für In-Circuit Debugging verfügbar?
- AVR: ab 40-Pin-Devices JTAG günstig verfügbar [Evertool], darunter nicht oder mit debugWIRE arg teuer.
- 8051: Derivate mit JTAG verfügbar. ICEen gebraucht erschwinglich.
- PIC: Entweder Microchips MPLAB ICD2 (€150-200) oder ein kompatibler Nachbau, wie z.B. http://www.stolz.de.be/
- MSP430: alle mit JTAG, Adapter sehr günstig/einfach zu bauen
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.