Mikrocontroller Vergleich

2005-09-16T17:28:42Z

84.154.149.161: JTAG auch bei Mega2560 und Mega644, also vom Chip weiterhin unterstützt

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 (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.

<b>Manches davon ist durchaus subjektiv. Bei abweichender Meinung bitte als Diskussion starten, nicht einfach löschen.</b>

'''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.

'''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).
* Zugriff auf I/O-Ports erfordert spezielle Zugriffsfunktionen.

'''AVR''':
* 2 Speicherklassen für Datenspeicher (RAM, ROM).

'''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-Architektur|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 existieren wohl, via Banking (Compiler-Support?).

'''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. 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:
<pre class="code">
port |= 0x03;
</pre>
übersetzt sich in
<pre class="code">
IN r,port
ORI r,0x03
OUT port,r
</pre>
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:
<pre class="code">
OR #0x03,port
</pre>

Code wie
<pre class="code">
port = (port & ~0x0F) | lcd_data;
</pre>
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:
<pre class="code">
PINA = (PORTA & 0x0F) ^ lcd_data;
</pre>

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
<pre class="code">
P1 = P1 | 0x01;
P1 = (P1 | 0x01) & ~0;
</pre>
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
[Evertool, Olimex, Erostech] oder einfach zu bauen. 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''':

==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.

==Links==

* [http://www.mikrocontroller.net/forum/read-1-185133.html#new Forum]
* [[8051]]
* [[AVR]]
* [[PIC]]
* [[Z8]]

[[Category:Mikrocontroller]]

Mikrocontroller.net - Benutzerbeiträge [de]

Mikrocontroller Vergleich