Mikrocontroller Vergleich

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche

Ein paar Kriterien für den CPU-Core und die µC-Familie.
Weitere vergleichende Informationen über verschiedene Controllerfamilien gibt der Artikel: Entscheidung Mikrocontroller sowie STM32 für Einsteiger. Für etwas erfahrene Anwender auch LPC1xxx für Umsteiger.

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.

ARM ist eine Firma, die Prozessorarchitekturen herstellt, und diese in Lizenz verkauft. Chipproduzenten wie ST, NXP, ATmel, Fairchild, uvm. haben Lizenzen gekauft und produzieren damit µC. Wenn in diesem Artikel von ARM gesprochen wird dann gibt es stark unterschiedliche Kerne, ARM7, ARM9, ARM11, Cortex-M0, Cortex-M3/M4, Cortex-A15 (und viele mehr). Zum Teil sind die Kerne für µC geeignet (ARM7, Cortex-M0..M4), andere für PC ähnliche Systeme (ARM11, Cortex-A15).

Für ARM gibt es eine ganze Reihe verschiedener Compiler, u.a.:

  • Von IAR eine auf 32KB begrenzte kostenlose Version eines umgänglicheren kommerziellen Compilers.
  • Vom GCC gibt es diverse Distributionen für die verschiedenen ARM-Kerne, einzeln oder in IDE's integriert, gratis oder kostenpflichtig; siehe ARM GCC.
  • Für alle CPUs von NXP - die LPCx Familie - stellt NXP eine kostenlose Plattform zur Verfügung, die hierdownloadbar ist.


Des Weiteren gibt es für MSP430 eine auf 4KB begrenzte kostenlose Version der Entwicklungsumgebung von IAR und eine kostenlose Version der Entwicklungsumgebung Code Composer Studio (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€ , freie Version codegrösseneingeschränkt), 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. Alternative: CC5X. Die freie Version davon wurde inzwischen ohne Codegrößenbeschränkung freigegeben, kann aber nur bis 16-bit integer / 24-bit Floating Point.

Für die PIC 18 gibt es den C18 von Microchip. Er ist frei erhältlich und hat ähnliche Einschränkungen wie der C30. Eine CC5x-ähnliche Variante gibt es unter dem Namen CC8E, der allerdings auf 128k Code beschränkt ist.

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.

Eine nette IDE für PIC12/16/18 bietet der Sourceboost-Compiler, für kleine Programme reicht die Freeware-Version absolut aus http://www.sourceboost.com/home.html

Für R8C/M16C gibt es eine Code-Größen-beschränkte Demoversion des Herstellers, sowie den GCC. Beide Compiler integrieren sich in die HEW (die IDE von Renesas), welche auch das Debugging mittels Software-Monitor oder Emulator unterstützt. Der GCC ist nach Registrierung bei Kpit Cummins erhältlich, die letzte Version ist 11.0x und wird nicht mehr weiterentwickelt. Die letzte Version ist jedoch problemlos im Archiv zu finden.

Für ST7 gibt es (teils limitierte) C-Compiler, teils mit IDE (z.ß. Cosmic und Ride). Toolchain von ST kostenlos erhältlich.

Von Toshiba gibt es für TLCS-870 mit den Starterkits eine IDE mit C-Compiler und Assembler. Ausserdem gibt es Toshibas eigene "C-Like Language". Diese Tools sind nicht frei downloadbar.

Zilog stellt für Z8_encore! 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


BASIC:

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", wobei die Originalversion von INTEL stammt. Dieser Interpreter unterstützt sogar Fließkomma-Arithmetik und ist als Freeware verfügbar.

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 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 Thumb2 codierte Befehle, wurde gegenüber Thumb erheblich erweitert. 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 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.

ST7:Akkumulatorarchitektur, Gemeinsamter Code/Datenadressraum (von-Neumann). 63 Befehle. Einheitlicher 64KB Adressraum für RAM und ROM.

TLCS-870: 8-Bit CISC-Architektur, aus Z80 weiterentwickelt. Gemeinsamer Adressraum für RAM und ROM bis 60KB ROM, darüber getrennt. Adressraum 64/128KB. Serie 870/X mit 1MB Adressraum existiert, aber nur als OTP/Maskenversion.

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:

Compiler Befehle(1) Bytes(1) Befehle(2) Bytes(2)
GCC AVR 24 48 24 48
Keil 8051 24 38 74 109
SDCC 8051 24 40 35 54
Zilog Z8e 21 54 27 73
PIC C18 26 52 95 206
SDCC PIC18 41 112 41 112
SDCC PIC16 26 52 - - (for pic16f84)
HEW R8C/M16C 20 48 20 48
GCC 68HC11 36 65 36 65
GCC MSP430 17 40 17 40
GCC ARM7 12 48 12 48
GCC ARM7-Thumb 20 40 20 40

(1): Lokale Daten ggf. statisch gespeichert, nicht reentrant.

(2): Lokale Daten auf dem Stack, also reentrant.

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).
  • Außerdem noch Adresserweiterungen durch Mapping, Paging und Banking

AVR:

  • 3 Speicherklassen für Datenspeicher (RAM, ROM, EEPROM).
  • In neueren Versionen von avr-libc kommt zwar eine 4. Klasse für die Fuse-Bits hinzu, die aber nur für die Konfiguration des Controllers verwendet wird und für das C-Programm selbst nicht relevant ist.

ARM, MSP430, R8C: 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öß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, ST7, TLCS-870: von Neumann-Architektur, problemlos.

Lineare Adressierung vom RAM?

8051, ARM, AVR, MSP430, R8C/M16C, ST7, TLCS-870, 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.

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: 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: 20/33-Pin/8KB-128K 80/208-Pins 34-512k mit internem Flash. Versionen mit internem Cache und externem Speicher sind praktisch beliebig weit ausbaufähig.

AVR: 6-Pin/0.5KB bis 100-Pin/256KB. 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, mittlerweile auch Typen mit 4KB bis 16KB FRAM erhältlich. 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, 18 und 25 MHz je nach Familie. 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.

R8C: TQFP, QFN 14 bis 100 Pins, 11 bis 88 I/Os. 256 bis 10K RAM, 2K bis 128K Flash, 0 bis 4K Data-Flash. 8MHz bis 32 MHz. -40°C bis 125°C.

ST7: 8 bis 80 Pins. SDIP, SOIC, LQFP, TQFP, QFN. 128 bis 2048 Bytes SRAM, 1 bis 60 kBytes Flash.

STM8: 20 bis 80 Pins. SDIP, SOIC, TSSOP, LQFP, QFN, UQFPN, WLCSP. 512 bis 6k Bytes SRAM, 4 bis 128 kBytes Flash, 384 bis 2k Bytes EEPROM.

TLCS-870: 20pin DIP bis 267FBGA. Daneben SDIP, SOIC, SSOP und (L/T)QFP. Relativ wenige Flash-Typen. RAM: 128 Bytes bis 4kB.

Z8e: 8 bis 80 Pins. DIP, SOIC, SSOP, QFP, TQFP, QFN. Bis 64KB Flash. 256 Bytes bis 4 kBytes 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.

Interrupt-feste (atomic) Programmierung von I/O-Ports

Siehe 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. Leider ist beim R8C/M16C/M32C die Adresse für das Port input Register mit der Adresse für das Port output Register identisch. Ein read/modify/write auf das Port output Register kopiert also bei Pins die auf Eingang stehen den eingelesenen Wert in das Port Output Register. Deswegen braucht man eine Interruptsperre wenn man einen Port Pin von input auf output umschalten will.

Zu ARM ist dazu keine allgemeine Aussage möglich. Je nach Implementierung des Herstellers wird das Problem teilweise durch entsprechend gestaltete I/O-Ports gelöst, in anderen Fällen ist erhebliche Wachsamkeit geboten. Atmel SAM7, LPC1xxx oder STM32 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.

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.

ARM, AVR, MSP430, Z8e und neuere Modelle der PIC-Familie besitzen diese Probleme nicht.

Priorisierte Interrupts

Unter 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 bei separaten Vektoren selbstverständliche Fähigkeit, anstehende Interrupts nach fester Priorität zu sortieren, ist damit nicht gemeint.

8051: Ja.

ARM7/9: Der 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.
ARM11, Cortex-Mx: Bei den neueren ARMv6M (ARM11, Cortex-M0(+)) und ARMv7M (Cortex-M3, M4(F)) Architekturen wurden die Interruptprioritäten fest in den Kern implementiert, dort hat jeder Interrupt eine 2-Bit (ARMv6M) bzw. 3-8 Bit (ARMv7M - die genaue Anzahl ist durch die Implementationen gegeben) Priorität die man auf Primary und Secundary unterteilen kann. Somit kann genau definiert werden welcher Interrupt einen anderen unterbricht und welcher warten muss bis einer mit einer höheren Priorität abgearbeitet wurde. Nesting von Exceptions ist problemlos möglich.

AVR: Nein, aber separate Vektoren für die einzelnen Interrupt-Quellen.

Anmerkung: Eine weniger wichtiger Interrupt Handler kann oft sofort nach Ansprung ein SEI ausführen, damit ein möglicherweise wichtigerer Interrupt Handler aufgerufen werden kann, weil bei den meisten Interrupts der Request bereits mit dem Aufruf des Handlers automatisch zurück gesetzt wird. Das trifft aber beispielsweise nicht beim TWI zu. Xmegas haben ein Event-System...."

MSP430: Nein, aber separate Vektoren für die einzelnen Interrupt-Quellen. Keine Priorisierung im Sinne der Präambel.

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: 64+6 Vektoren, Priorität für jede Interrupt-Quelle frei einstellbar, Nesting möglich.

ST7: Nein. 16 Vektoren mit fixer (absteigender) Priorität.

Z8e: 3 Prioritäten, vektorisiert.

Spannungsversorgung

8051, AVR, PIC: Modellabhängig 2-5V problemlos, ältere ab 3V. PICs für 2-4V sind schlecht verfügbar. Ungeregelter Batteriebetrieb möglich.

ARM: 3,3V-Versorgung, je nach Modell mehr oder weniger 5V-kompatibel. Einige (vor allem ältere) Modelle benötigen eine separate 1,8V-Versorgung für den Core. Ungeregelter Batteriebetrieb möglich. z.B. können Prozessoren der LPC1xxx- oder STM32-Reihe von 1,65...3,6V betrieben werden und benötigen keine separate Stromversorgung.

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.

PIC24 und dsPIC33: 2-3,6V. Pins die keine analogen Funktionen übernehmen können sind 5V tolerant.

R8C: 2.7V - 5.5V, zwischen 2.7V und 3V etwas reduzierte Maximaltaktrate.

ST7: 2,4-5,5V

STM8: 1,65 - 5,5V

TLCS-870: 2,7-5,5V. Serie 870/C 1,8-5,5V.

Z8e: 1,8-3,6V, I/Os 5V-tolerant.

Programmierung in der Schaltung

Gerä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.

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 oder SWD, z. B. bei Philips LPC2000 über RS232 und Atmel SAM7 über USB (bei letzterem sehr unbequem und langsam!). Von NXP gibt es ein sehr preiswertes Entwicklungskit (ca. 25€ für Evaluation-Board incl. USB-JTAG-SWD Programmer und Debugger), erhältlich z.B. bei Watterott. Damit ist eine Programmierung über SWD am USB-Port des PCs problemlos möglich.

AVR: Je nach Derivat verschiedene bzw. mehrere Möglichkeiten: JTAG, DebugWire, ISP, HV, PDI. Über ein ISP-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. Alternativ auch ein einfach zu bauender Dongle für die RS232-Schnittstelle des PC. 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)

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 (~50€ Pickit 2\Pickit 3,~150€, ICD2 von Microchip). Bootloader müssen generell vorher mit einer der vorher genannten Möglichkeiten auf den Chip geflasht werden.

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

ST7: Via ein mit der Schaltung (mittels mindestens 4poligen Kabels) kommunizieredes Debug-Interface. Offenes ST-Protokoll "ICC".

TLCS-870: Flash-Typen besitzen maskenprogrammierten Bootloader.

Z8e: Via Zilogs Debug-Interface "Smart Cable".

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.

ARM:
die meisten JTAG und SWD


EFM32 unterstützt nur SWD.

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.

ST7: Via ein mit der Schaltung (mittels mindestens 4poligen Kabels) kommunizieredes Debug-Interface. Offenes ST-Protokoll "ICC".

Z8e: Debugging möglich mit "Smart Cable" (kein JTAG), Anschluss über USB oder seriell Schnittstelle

Starterkits

8051: Keil MCBx51 http://www.keil.com/mcbx51 (z. B. für ~240€ von mouser.com)

ARM: allgemein: 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), Launchpad: http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_%28MSP-EXP430G2%29

PIC: http://www.microchipdirect.com/ , Velleman-Kit K8048 (www.velleman.be) , http://www.mikroe.com/eng/categories/view/6/pic-development-tools/

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

STM8: STM8S-Discovery

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

Beschaltungsaufwand

8051, AVR, PIC, MSP430, R8C, ST7, Z8e: 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.

Links

Abgerufen von „https://www.mikrocontroller.net/index.php?title=Mikrocontroller_Vergleich&oldid=99577“