|
|
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. Für PIC 10/12/16 gibt es den HI-TECH C-PRO von HI-TECH(Microchip) in einer freien Version. Der CC5X unterstützt zwar keine High-End PICs, dafür die meisten Mid-Range. Die 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. Für die PIC 18 gibt es den C18 von Microchip. Er ist frei erhältlich und hat ähnliche Einschräkungen wie der C30. Für die PIC24 und dsPIC gibt es den C30 von Microchip. Er basiert auf gcc und ist frei erhältlich, wobei nach 6 Wochen nicht mehr alle Optimierungsstufen wählbar sind, dann maximal -O1. Wie für alle PIC ist mit dem MPLAB eine kostenlose IDE mit Debugger und Simulator verfügbar. 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 sehr guten 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,- € ) Elektor-Verlag 'Pascal für 8051 und Derivate' Buch+Compiler(Vollversion) AVRco Pascal Compiler (http://www.e-lab.de/), Kostenlose Version für Mega8/88
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 RISC-Architektur mit vollständiger Orthogonalität. 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). PIC24: Register-orientierte 16-Bit Architektur mit getrennten Adressräumen für RAM und ROM, wobei ein Teil des ROM in den RAM-Adressbereich eingeblendet werden kann. Fast alle Befehle sind auf Register und RAM anwendbar, incl. Bitmanipulationen. dsPIC: wie PIC24, mit zusätzlichen DSP Befehlen. 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, R8C: 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. PIC24 und dsPIC können einen Teil des ROM in den RAM-Adressbereich einblenden. 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: 14-Pin DIP/1KB bis 113-Pin BGA/256KB. DIP, SOIC, TSSOP, QFN, TQFP und BGA erhältlich, in DIP und BGA jedoch nur wenige Typen verfügbar. Architekturbedingte Grenze von 64KB für Code+Daten wird in den großen Versionen durch 20-bittige Adressen umschifft. Taktfrequenz: maximal 8, 16 und 18 MHz je nach Familie. 25 MHz-Versionen in Kürze. Stromaufnahme: Rund 2 uA im LPM3 (real time clock mode) bis ca. 5 mA, typisch 200 µA pro MHz. 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. PIC24 und dsPIC: 18 bis 100-Pin mit 16 bis 256kB Code und bis zu 16kB RAM. Generell sind alle als TQFP und QFN erhältlich, die 18 und 28 Pin Modelle gibt es auch als SDIP und SSOP und SOIC. Es gibt Modelle mit 16 und 40MHz. eZ8: 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. Bei den LPC2000 gibt es zwei getrennte Register, eines zum Setzen, das andere zum Löschen einzelner Pins. In einem weiteren Register können Bits ausmaskiert werden. Es gibt also kein read-modify-write. Gut gelöst für Push/Pull-Ausgänge, aber eine äquivalente Steuerung der Richtung wurde vergessen, was Open-Drain Pins erschwert. Implementierungen auf Basis des Cortex M3 oder der ARM Port-Macrocell verwenden statt dessen Adressbits zur Maskierung. 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 InterruptsUnter priorisierten Interrupts versteht man die Fähigkeit, den einzelnen Interrupt-Quellen eine Priorität zuweisen zu können um ohne Reprogrammierung der Interrupt-Quellen einen laufenden Interrupt ausschliesslich durch Interrupts höherer Priorität unterbrechbar machen zu können. Die einfache und selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint. 8051: 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 zu alten 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: Ja, 16 vollpriorisierte Vektoren, davon 14 global maskierbar. 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. PIC24 und dsPIC haben 7 Prioritäten und für jeden Interrupt einen eigenen Interruptvektor. 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 PIC24 und dsPIC33: 2-3,6V. Pins die keine analogen Funktionen übernehmen können sind 5V tolerant. 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, TI "Spy BiWire" und über integrierten Bootloader. (Schaltung zur Ansteuerung via RS232 im Datenblatt) 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/. Alternativ das PICKit 2 für ~40€, dass neben dem Programmieren und Debuggen über USB auch noch als RS232-Brücke und einfacher Logic-Analyzer benutzt werden kann. 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: http://www.microchipdirect.com/ , 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 |