Dieser ArtikelBenutzerSuche |
AVR PIC 51-VergleichEin paar Kriterien für den CPU-Core und die µC-Familie. [bearbeiten] 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 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. Des Weiteren gibt es für MSP430 eine auf 4KB begrenzte kostenlose Version der Entwicklungsumgebung von IAR und eine auf 8KB begrenzte kostenlose Version der Entwicklungsumgebung Code Composer Essentials (basiert auf Eclipse) von Texas Instruments. Für PIC und 8051 kann man entweder den Open-Source-Compiler SDCC verwenden (brauchbar, aber nicht mit GCC vergleichbar) oder diverse Löhnwares, bis 4-stellige Beträge (Keil: 2600€), teils auch als Demoversion mit Tricks. Auch der offizielle C18-Compiler kann als großzügiges Demo heruntergeladen werden. 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 Für R8C/M16C gibt es eine Demoversion des Herstellers und eine noch ziemlich frische (lies: Stand 2005 nicht ausgereifte) Version vom GCC. Zilog stellt für Z8e eine unbeschränkte IDE mit C-Compiler, Debugger und Simulator kostenlos per Download zur Verfügung. Pascal Für PIC,DSPIC und AVR gibt es einen sehrguten PASCAL-Compiler "MikroPascal" der, in der Downloadversion Code-Size begrenzt ist, und den man zu moderaten Preisen zur "Vollversion" aufrüsten kann. http://www.mikroelektronika.co.yu/ ( ab 149,- € ) Pascal-Alternativen: Elektor-Verlag 'Pascal für 8051 und Derivate' Buch+Compiler(Vollversion) AVRco Pascal Compiler (http://www.e-lab.de/)
Sowohl für den AVR als auch für die 8051er gibts von MCS-Electronics eine Demoversion eines BASIC-Compilers, der leicht im Funktionsumfang und Codegröße eingeschränkt ist. [1] Darüber hinaus kursieren im Netz Versionen eines BASIC-Interpreters für 8052er mit dem Namen "8052 AH-BASIC". Dieser Interpreter unterstüzt sogar Fließkommarithmetik und soll als Freeware verfügbar sein. [bearbeiten] ArchitekturBetrifft 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 mit dem ARM7TDMI-Core (Architektur V4 = ARMv4T) stehen 2 Befehlssätze zur Verfügung: 32bit-codiert für Tempo, sofern der Speicherdurchsatz das zulässt, und 16bit-codiert (Thumb) für kompakte Programme. Cortex M3 (ARMv7) kennt ausschliesslich 16bit codierte Befehle. 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.Bemerkung: Laut Wikipedia wurde der Controller während der Entwicklungsphase für den Einsatz von C-Compilern optimiert. 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). Mit der neueren 16-Bit (Programmspeicherbreite) Architektur wurden einige dieser Probleme beseitigt, andere nicht. Microchip hat auch eine Familie mit 16-Bit Datenbusbreite angekündigt. R8C: 16-Bit 2-Adress CISC-Architektur. Einheitlicher 64KB Adressraum für RAM und ROM. Gute Zielmaschine für C-Compiler. M16C: Unter Bezeichnung M16C existieren sich zwei verschiedene inkompatible Architekturen. Die Modelle bis /6x sind grundsätzlich identisch mit R8C, die /8x Modelle mit M32C (hier nicht näher betrachtet). Der 64KB RAM-I/O-Adressraum ist ein Teil des 1MB großen Gesamtadressraumes, Daten im ROM liegen jedoch ausserhalb dieser 64KB und sind daher anders als beim R8C nicht mit 16-Bit Zeigern adressierbar. Gute Zielmaschine für spezialisierte C-Compiler, GCC jedoch tut sich etwas schwer mit den Adressräumen. 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 Kleiner nicht repräsentativer Compiler-Vergleich. Verwendet wurde eine Variante des crc8-Code von Colin O'Flynn. Jeweils kleinstes Speichermodell, auf Platz optimiert:
(1): Lokale Daten ggf. statisch gespeichert, nicht reentrant. (2): Lokale Daten auf dem Stack, also reentrant. [bearbeiten] Sind CPU-spezifische Erweiterungen in C erforderlich?8051:
AVR:
ARM, MSP430: nein. PIC:
Z8e:
[bearbeiten] 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ößeren jedoch schon. Bei AVR/GCC ziemlich fehlerträchtig. M16C: Hängt vom Compiler ab. Mit 16-Bit Zeigern (GCC) nicht, 20-Bit Zeiger sind ineffizient. ARM, MSP430, R8C: von Neumann-Architektur, problemlos. [bearbeiten] Lineare Adressierung vom RAM?8051, ARM, AVR, MSP430, R8C/M16C, Z8e: kein Problem. PIC: PIC18 ja, PIC16,PIC12,PIC10 nein. RAM-Puffer die größer sind als das RAM in einer Bank sind nur mit Klimmzügen möglich. [bearbeiten] SkalierbarkeitVor 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: 8-Pin/1KB 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. ARM: 48-Pin/32KB, bis 512K mit internem Flash. Versionen mit internem Cache und externem Speicher sind praktisch beliebig weit ausbaufähig. 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 großer 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, sind 8/16-Bit-Controller 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 große Programme zu Programm- und Datenstrukturen neigen, die sich auf 8-Bit Prozessoren schlecht abbilden lassen. [bearbeiten] Interrupt-feste Programmierung von I/O-PortsSiehe http://www.mikrocontroller.net/articles/Interrupt. Das ist besonders bei AVR (ausser 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. PIC, 8051, MSP430, R8C/M16C, Z8e können AND/OR/XOR zum Port hin, daher ist bei geeigneter Programmierung das Problem auch ohne Abschalten der Interrupts vermeidbar. Zu ARM ist dazu keine allgemeine Aussage möglich. Je nach Implementierung wird das Problem teilweise durch entsprechend gestaltete I/O-Ports gelöst, in anderen Fällen ist erhebliche Wachsamkeit geboten. Atmel SAM7 bereitet hier weniger Probleme als Philips LPC2000. 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. [bearbeiten] Zugriff auf I/O-PortsDer 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. ARM, AVR, MSP430, Z8e und neuere Modelle der PIC-Familie besitzen diese Probleme nicht. [bearbeiten] Priorisierte Interrupts8051: Ja. ARM: Der ARM-Core unterstützt 2 Prioritäten mit entsprechenden Vektoren. Oft ist jedoch ein separater priorisierter und vektorisierter Interrupt-Controller mit integriert (Atmel, NXP, Cortex ja, Analog Devices nein). Interrupt-Nesting ist dank eines Designfehlers etwas umständlich, repariert in ARMv7 (Cortex M3). 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". Wenn aber ein Interrupt in der Interruptroutine ausgelöst wird, wird er später der internen Priorität nach ausgeführt. Immerhin haben Interruptquellen im Gegensatz zum PIC ihre eigenen Interruptvektoren, so dass 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 muss gewährleistet sein, dass 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. Einfache PIC12 (12F508/509, 16F505) kennen gar keine Interrupts. 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, muss 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. R8C/M16C: 7 Prioritäten, vektorisiert. Z8e: 3 Prioritäten, vektorisiert. [bearbeiten] Spannungsversorgung8051, AVR, PIC: 3-5V problemlos (evtl. eingeschränkte µC-Auswahl?). Ungeregelter Batteriebetrieb möglich. Einzelne AVR auch bis 1.8V. LV-PICs auch bis 2,2V ARM: 3,3V-Versorgung, 5V-kompatibel. Je nach Modell ist eine separate 1,8V-Versorgung für den Core notwendig. Kein ungeregelter Batteriebetrieb möglich. MSP430: nur 1.8-3.6V. Nicht 5V-kompatibel, 5V-Peripherie für I2C/RS485/CAN/... ist also nur mit Pegelkonvertierung einsetzbar. Ungeregelter Batteriebetrieb möglich. Z8e: 3,3V-Versorgung, 5V-kompatibel. [bearbeiten] Programmierung in der SchaltungGeräte mit Debugging-Interface (s.U.) lassen sich i.d.R. auch damit programmieren. Siehe dazu nächsten Abschnitt. Die meisten Controller können sich selbst programmieren, Bootloader per RS232,CAN,usw sind dann problemlos realisierbar. Nur müssen solche Bootloader erst einmal auf den Chip programmiert werden. PIC: Entweder über die serielle ICSP-Schnittstelle (dafür gibt es Baupläne für billige ParPort-Programmer incl. guter Software) oder mit dem InCircuit-Debugger (~150€, ICD2 von Microchip). Bootloader müssen generell vorher mit einer der vorher genannten Möglichkeiten auf den Chip geflasht werden. 8051: Verschieden, je nach Hersteller und Modell. Im Unterschied zu den anderen hier betrachtete Controllern existieren viele nicht in der Schaltung, sondern nur mit speziellen Interfaces programmierbare 8051 Modelle. Modelle mit seriellem Bootloader via UART, SPI, CAN oder USB existieren. ARM: Am besten über JTAG, je nach Hersteller und Familie auch mit Bootloader, z.B. bei Philips LPC2000 über RS232 und Atmel SAM7 über USB (bei letzterem sehr unbequem und langsam!). AVR: Über ein an SPI orientiertes proprietäres Interface. Ist via Parallelport günstig herzustellen; der Adapter ist im besten Fall genau 5 Widerstände teuer, professioneller mit einem Tri-State-Bustreiber etwa 5-15 EUR. Darüberhinaus auch mit HV-Programmer (z.B. auf dem STK500), der u.U. auch nötig ist um falsch gesetzte Fuses wieder zu "reparieren". MSP430: Via JTAG-Interface und über integrierten seriellen Bootloader. (Schaltung zur Ansteuerung über RS232 ist im Datenblatt angegeben) R8C: Via UART (RS-232 oder USB-RS-232 Konverter) mit Flash-Tool (Windows, Linux). Variante über Bootloader ebenfalls möglich (wird vom Software Emulator-Debugger benutzt). Z8e: Via Debug-Interface. [bearbeiten] Debugging in der SchaltungIst beispielsweise ein günstiges JTAG-Interface für In-Circuit Debugging verfügbar? 8051: Derivate mit JTAG verfügbar. ICEen gebraucht erschwinglich. ARM: alle mit JTAG.
AVR: für ATmega16/162/32/128 ist JTAG günstig verfügbar (Olimex, Erostech) bzw. einfach zu bauen (Evertool). ATmegas ab 2005/2006 mit JTAG sind zu dieser Billigvariante inkompatibel. Für diese und den debugWIRE der ATtinys und ATmegaX8 existiert das JTAG ICE mkII von Atmel, aber recht teuer, sowie der preiswerte AVR Dragon. MSP430: alle mit JTAG, Adapter sehr günstig/einfach zu bauen. Neuere Geräte mit Spy-by-Wire (braucht weniger Pins als JTAG). PIC: Entweder Microchips MPLAB ICD2 (€150-200) oder ein kompatibler Nachbau, wie z.B. http://www.stolz.de.be/ R8C: On-Chip Debugging ist mit dem E8 Hardware On-Chip Debugging Emulator möglich (kein JTAG). Ausserdem ist Debugging auch über einen normalen RS232 Anschluss möglich. Der E8 verwendet ein syncrones serielles Protokoll, die RS232 ein asyncrones. Daher ermöglicht der E8 das Debugging bei jeder beliebigen Taktfrequenz, bei RS232 gibt es da Einschränkungen. Z8e: Debugging möglich mit "Smart Cable" (kein JTAG), Anschluss über USB oder Seriell [bearbeiten] Starterkits8051: Keil MCB900 (http://www.keil.com/mcb900) ARM: http://www.olimex.com (z.T. hier im Shop erhältlich), http://www.embeddedartists.com, http://www.mct.de AVR: STK200, STK500, AVR_Butterfly MSP430: http://www.olimex.com (z.T. hier im Shop erhältlich), ez430 (http://www.ti.com/ez430) PIC: Velleman-Kit K8048 (www.velleman.be) R8C: Mehrere (Google Suche). Am weitesten verbreitet ist vielleicht das R8C/13 Starterkit inkl. Entwickler-CD von Glyn/Elektor (Beilage Elektor 12/2005 (ausverkauft) bzw. diverse Drittanbieter). 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. [bearbeiten] GehäuseMit DIP oder PLCC bastelt es sich leichter als mit *QFP. Die Domäne von AVR/PIC/i51. Für MSP430 gibt es günstige fertig bestückte DIP-Adapter hier im Shop (MSP430x2xx gibt es auch in 14-Pin DIP-Gehäuse). Z8e-Chips existieren ebenfalls in DIP, sind aber schlechter verfügbar. [bearbeiten] BeschaltungsaufwandAVR, PIC, 8051, Z8e, MSP430, R8C: gering, i.d.R. sind Versionen mit integriertem Oszillator verfügbar, so dass man praktisch nur die Versorgungsspannung (nebst Abblockkondensator) braucht. ARM: aufwendigere externe Takt- und Spannungserzeugung, manchmal 2 Betriebsspannungen benötigt; Tendenz aber fallend. [bearbeiten] Links |