Entscheidung Mikrocontroller

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

Die meisten Anfänger stellen sich die Frage, welchen Mikrocontroller sie verwenden sollen. Es gibt Dutzende Hersteller, und jeder davon hat unzählige Varianten im Angebot. Stellt man die Frage in einem Diskussionsforum, dann bekommt man viele verschiedene (sich teilweise widersprechende) Antworten. Bei der Entscheidung sollten u.a. die unten stehenden Kriterien beachtet werden. Dieser Artikel ist primär für Hobbyisten gedacht, da im professionellen Einsatz oftmals völlig andere Kriterien beachtet werden müssen. Weitere vergleichende Informationen über verschiedene Controllerfamilien gibt der Artikel: Mikrocontroller_Vergleich sowie STM32 für Einsteiger. Für etwas erfahrene Anwender auch LPC1xxx für Umsteiger.

Verfügbarkeit

  • Während man manche Mikrocontroller an jeder Straßenecke bekommt, sind andere nur in großen Stückzahlen und mit Gewerbenachweis erhältlich. Dazu einfach mal in die Kataloge der einschlägigen Privatkundenhändler schauen. Dabei auch darauf achten, dass der gewünschte Controller auch in der richtigen Bauform erhältlich ist (DIP, TQFP, MLF usw.), s.u.
  • Ab und zu kündigen Hersteller ein neues Modell an (und veröffentlichen das Datenblatt dazu), können aber erst ein Jahr später nennenswerte Stückzahlen liefern. Also den Controller nicht einfach anhand der Übersichten beim Hersteller aussuchen, sondern überprüfen, was die Händler auch wirklich liefern können.
  • Lebenszyklus: Kein Modell wird ewig hergestellt. Deswegen sollte man überprüfen, ob der Hersteller vielleicht schon angekündigt hat, dass er ein bestimmtes Modell nicht mehr herstellen will. Die Hersteller schreiben dann z. B. "Mature Product (Not Recommended for New Designs)". Für Neuentwicklungen oder den Einstieg sollte man folgende Modelle nicht verwenden:
    • AVR AT90-Reihe,
    • AVR ATMega 103(L), 161(L), 163(L), 323(L).
  • Für alle abgekündigten AVR-Controller gibt es jedoch pin- und funktionskompatible Nachfolger. Daher kommt es nur in den seltensten Fällen zu Problemen. Probleme können nur entstehen, wenn ein Programm nur in kompilierter Version zur Verfügung steht.
  • Dagegen sind Mikrocontroller der MCS51-Familie von Intel eher für langfristige Investitionen geeignet. Der 8051 wurde 1979 (!) als erstes Mitglied dieser Familie vorgestellt. Heute gibt es bereits hunderte von 8051-Derivaten von dutzenden von Halbleiterherstellern, zum Teil auch mit weiterentwickelten Prozessorkernen. Wird ein Derivat tatsächlich mal abgekündigt, findet man bei dieser Riesenauswahl meist leicht adäquaten Ersatz.

Preis

Einerseits kann es lästig sein, wenn man durch die Verwendung eines kleineren Modells 2 Euro gespart hat und dann mit dessen Unzulänglichkeiten kämpft, andererseits ist ein versehentlich zerstörter Chip für 30 Euro ziemlich ärgerlich. Auch ist es oft ganz praktisch, wenn man einige Controller auf Vorrat hat.

Zum Preis eines einzelnen Mikrocontrollers kommen noch die Kosten für die Entwicklungswerkzeuge, wie Compiler, Programmübertragung und Debugging hinzu (s.u. Programmiersprache und Programmübertragung).

Dokumentation

Die wichtigste Informationsquelle zu einem Mikrocontroller ist das Datenblatt. Diese gibt es heutzutage aber fast ausschließlich in Englisch. Wer damit nicht zurecht kommt, muss vorher schauen, ob es irgendwelche Tutorials oder Bücher in seiner Lieblingssprache gibt.

Je mehr Funktionen ein Mikrocontroller beherrscht, desto umfangreicher wird auch das Datenblatt. Das führt dazu, dass bei manchen Mikrocontrollern das Datenblatt über 1000 Seiten hat. Da ist die Gefahr groß, dass ein Anfänger den Überblick verliert.

Unterstützung/Community

Gerade als Anfänger ist man oft auf die Hilfe anderer angewiesen. Da empfiehlt es sich, der Masse hinterherzulaufen und keine exotischen Typen zu verwenden. Im Bastlerbereich populäre Mikrocontroller-Familien sind die AVRs von Atmel und die PICs von Microchip. Für diese Architekturen gibt es z. B. im Forum dieser Internet-Seite gute und meist auch schnelle Hilfestellung bei Problemen.

Bauformen

Neben den klassischen (bedrahteten) Bauformen setzt sich heutzutage SMD immer mehr durch. Manche Mikrocontroller sind nur noch in SMD-Bauformen erhältlich. Für SMD benutzt man üblicherweise geätzte Platinen oder Adapter/Sockel (die aber wieder extra kosten). Will man mit Lochrasterplatinen oder Breadboards arbeiten, dann braucht man die klassischen Bauformen, z. B. PDIP. Zu beachten ist dabei, dass es PDIP oft nur bis DIP40 (also mit 40 Pins) gibt, d.h. einen Mikrocontroller mit 50 I/O-Pins kann es dann nur als SMD geben.

Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:

  • MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)
  • AVR ATMega 169

In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:

  • AVR ATMega 88A, 164A, 324A, 644A
  • AVR ATTiny: Praktisch alle, z. B. ATTiny 13A, 24A, 25, 26, 2313A
  • viele 8051-Derivate, z. B. Atmel 89S8252
  • (nahezu) alle Microchip PIC Controller die mit 40 oder weniger Pins auskommen. Auch 16Bit Varianten und sogar einige Vertreter der 32Bit PIC Familie

Spannung

Während früher die meisten Mikrocontroller und die gesamte Peripherie mit 5V liefen, so gibt es heute auch alle möglichen anderen Varianten. Zu beachten ist:

  • Controller und Peripherie müssen zusammenpassen. Man kann nicht einfach (ohne weitere Vorkehrungen) ein 3,3V-RAM an einen 5V-Controller anschließen und umgekehrt.
  • Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: LPC2100).
  • Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z. B. bei den LPC2100.
  • Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein Spannungsregler (z. B. 78xx) ist also Pflicht!
  • Bei Batterien und Akkus sinkt die Spannung ab, wenn sie leerer werden. Braucht der Controller z. B. mindestens 2,7V, dann wird man mit zwei 1,5V-Batterien nicht lange Freude haben (außer man benutzt spezielle Schaltregler).

Stromverbrauch

Im Vergleich zu PC-Prozessoren (Pentium, Athlon usw.) brauchen Mikrocontroller relativ wenig Strom. Will man sie allerdings mit Batterien betreiben, dann wird der Stromverbrauch plötzlich doch wichtig. Die meisten Mikrocontroller besitzen hierfür Stromsparmodi, mit denen man den Controller teilweise abschalten kann. Für einen extrem geringen Stromverbrauch sind z. B. die MSP430-Controller oder EFM32-Controller optimiert.

Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab.


Frequenz ATMega8 (2.7V) ATMega8 (5.0V) PIC16LF84A(2.0V) PIC16F84A (5.5V) MSP430F2618 (3V) Einheit
32KHz 62 80 45 - k.A. µA
100KHz 0,3 0,5 - - 0,084 mA
1MHz, 2MHz* 1,5 2,3 4 - 0,5
8MHz, 4MHz* 5 7/15** - 4,5 4,2
16MHz, 20MHz* - 20 20 9,5 (3,3V)

[*] Abweichende Taktangabe für PIC16*F84A, da hier keine entsprechenden Werte für die Frequenzen des ATmega8 im Datenblatt (PIC16F84A Data Sheet, Microchip 2001, 35007b.pdf) vorliegen.

[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).

Takt/Geschwindigkeit

Einerseits wünscht man sich oft einen möglichst schnellen Controller, insbesondere als Anfänger, wenn man effiziente Lösungen noch nicht so kennt, andererseits schlägt sich ein hoher Takt auch im Stromverbrauch und im Preis nieder. Man sollte sich dabei nicht von den hohen Taktraten der PC-Prozessoren irritieren lassen. Für viele Anwendungen reicht 1-MHz-Takt völlig aus.

Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann:

  • Während manche Controller 12 Takte für einen Befehl brauchen (z. B. die Original-8051), kommen andere mit einem Takt pro Befehl aus (z. B. AVR).
  • Manche Controller unterstützen gewisse Operationen hardwareseitig, die auf anderen Controllern in Software nachgebildet werden muss. Beispiele sind z. B. Multiplikation und Division. Wer in einer Hochsprache programmiert, merkt davon nicht viel, da es dort die Befehle sowieso zur Verfügung stehen, aber sie brauchen auf einem Controller ohne Hardwareunterstützung eben deutlich länger.
  • Die Datenbus- bzw. Registerbreite spielt eine wichtige Rolle, weil man z. B. für eine 16-Bit-Addition auf einer 8-Bit-CPU zwei Befehle und auf einer 16-Bit-CPU nur einen Befehl braucht.

Bitbreite

Wie gerade angesprochen ist auch die Bitbreite (8, 16 oder 32 bit) mitentscheidend für die Verarbeitungsgeschwindigkeit. Da der Preis in etwa linear mit der Bitbreite steigt, sind 8-Bit-Controller nach wie vor am verbreitetsten. Der Compiler verdeckt das Problem der unterschiedlichen Bitbreiten, indem er für eine 32-Bit-Operation entsprechend viele kleinere Operationen compiliert.

Als Faustregel gilt:

  • Rechenintensive Programme, insbesondere mit 32-Bit-Zahlen oder -Zwischenergebnissen oder gar Gleitkommazahlen, gehören in einen 32-Bit-Controller. Das betrifft insbesondere digitale Filteralgorithmen, die zumeist schnell ablaufen müssen. In der Regel haben 32-Bit-Controller auch höhere Taktraten, etwa 60 MHz (ARM7) statt 16 MHz (AVR).
  • Programme, die mehr als 64 KByte adressieren müssen (etwa eine SD-Karte) sollten ebenfalls einen 32-Bit-Controller abbekommen, um die stets erforderlichen Adressrechnungen nicht allzu umständlich werden zu lassen, auch wenn es in diesem Fall fast nur um leichter implementierbare Strichrechenarten geht.
  • Operiert man mit vielen 16-Bit-Zahlen, typischerweise bei der Messwerterfassung von einer Datenquelle mit einer Abtastrate im kHz-Bereich oder mit 16-bit-Timern, erspart man sich eine Reihe Probleme durch die Auswahl eines 16-Bit-Controllers. Auch 32-bit-Adressen lassen sich noch halbwegs vernünftig berechnen.
  • Alles andere passt in einen 8-Bit-Controller, oder, wenn's ein bisschen knapp wird oder andere Vorlieben / Vorkenntnisse dagegen sprechen, in einen 16-bit-Controller. Auch mit Gleitkommazahlen kann man damit hantieren, wenn auch im Schneckentempo; für Anzeigezwecke, etwa bis 50 Werte pro Sekunde reicht das vollkommen.
  • Zu guter letzt, wer's ganz sportlich mag, steckt alles in einen 8-Bit-Controller, und wenn es Stunden für die effiziente Implementierung braucht.

4-Bit-Controller sind praktisch vom Markt verschwunden. Sie sind am billigsten gewesen und nur in Assembler zu programmieren. Ihr Einsatz lohnte sich nur in Massenartikeln, etwa analogen Satellitenreceivern.

Speicher

Während früher oft nur die Register im Mikrocontroller waren, und der gesamte restliche Speicher extern angebunden werden musste, so sind heute die Speicher oft komplett im Mikrocontroller integriert. Das bedeutet aber teilweise auch, dass man sie nicht erweitern kann. Wichtig ist dabei u.a. die Größe des Programmspeichers (meist ein Flash-ROM) und das SRAM. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.

Zu unterscheiden sind hier außerdem Controller in Von-Neumann-Architektur und Harvard-Architektur. Bei letzterer liegen Programmspeicher (ROM) und Datenspeicher (RAM) in getrennten Speicherbereichen; dies hat den Nachteil, dass für den Zugriff auf den Programmspeicher spezielle Befehle notwendig sind (was die Verwendung von im ROM abgelegten Daten in C-Compilern ziemlich umständlich macht), und dass man keine Programmteile direkt aus dem Datenspeicher ausführen kann.

Onboard-Peripherie

Mikrocontroller haben meist eine ganze Menge Funktionen integriert, z. B. AD-Wandler, I²C-Bus, SPI, PWM, RS-232 usw. usf. Der Vorteil liegt darin, dass der Controller damit mehrere Dinge gleichzeitig machen kann. Dadurch steigt zum einen die Gesamtleistung des Controllers, zum anderen sind viele Dinge zeitkritisch, und die Programmierung ist deutlich einfacher, wenn man zehn zeitkritische Dinge gleichzeitig erledigen muss.

Störfestigkeit

Eigentlich ein wichtiges Thema, andererseits findet man dazu nur sehr wenig Informationen. Bekannt ist beispielsweise, dass bei der AVR-Familie die ATmegas deutlich störfester sind als die alten AT90S.

Programmiersprachen

Den direktesten Zugriff auf die "Innereien" eines Prozessors hat man mit Assembler. Dies ist jedoch gleichzeitig - zumindest auf den ersten Blick - die "abschreckendste" Sprache, denn sie erfordert einen hohen Lernaufwand. Aufgrund stark unterschiedlicher Befehlssätze verschiedener Controllerfamilien ist das Gelernte nie 1-zu-1 übertragbar und meist nur direkt auf einen einzigen Prozessor oder allenfalls auf eine Familie "verwandter" Produkte anwendbar. Dennoch kann man sich mit einiger Erfahrung recht schnell in einen anderen Befehlssatz einarbeiten. In bestimmten Bereichen oder Teilen eines Projekts wird die Verwendung von Assembler dennoch unabdingbar sein. (Diese Teile mögen projektabhängig zwischen 100% oder auch nur deutlich unter 1% umfassen.)

Die Auswahl der richtigen Programmiersprache hängt auch stark vom geplanten Einsatzzweck ab. Ein Elektrotechnik-Student, der sich für sein späteres Berufsleben vorbereiten möchte, sollte sich mit C und Assembler befassen. Wer dagegen gar nicht vorhat sich allzu tief einzuarbeiten und sowieso schon Basic oder Pascal kann, der sollte zu diesen Sprachen greifen.

Wer Programme schreibt, die er später auch mit anderen größeren µC weiter verwenden möchte, der sollte auf Assembler ganz verzichten und nur in der Programmiersprache schreiben, die von den gewünschten µC unterstützt werden. In der Regel ist das C, in C werden auch die meisten Demo-Beispiele und Bibliotheken der µC Hersteller geschrieben, somit kann man deren Demos leichter in das eigene Programm einbinden.

Für einige Controllerfamilien (z. B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen GNU-C-Compilers, wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.

Für die LPC Prozessorfamilie ist eine größenlimitierte kostenlose Entwicklungsumgebung erhältlich. Informationen unter code-red: Die auf Eclipse basierende Entwicklungsumgebung ist nach der Installation bis 8k freigeschaltet und nach einer einfachen und kostenlosen Registrierung für 512kB. Die IDE ist auch für Linux verfügbar. Hier die Installationsanleitung

Debugging

Bei der Fehlerbeseitigung trennen sich Profi von Amateur, und es kann richtig teuer werden. Genau hier haben die Hersteller von Mikrocontrollern und/oder Compilern eine Möglichkeit gefunden, den Gelegenheitsprogrammierer abzuweisen und nur den zahlenden Profi vorzulassen.

Die preisgünstigste, aber auch unkomfortabelste Art des Debuggings ist der Einbau von Testcode in das Programm. Dieser Testcode informiert den Programmierer über erreichte Programmpunkte und dabei aufgetretene Datenwerte. Die Ausgabe erfolgt per optisch/akustischer Anzeige oder serieller Schnittstelle. Der Nachteil dieser Methode liegt in ihrem Zeitaufwand. Für jedes Problem muss ein kurzes Stück Testcode erdacht und in das Programm eingefügt werden. Danach wird das Programm kompiliert/assembliert und in den Flashspeicher des Mikrocontrollers gebrannt. Zuguterletzt muss das Programm von Beginn an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.

Deutlich effektiver ist die Fehlersuche mittels einer in die PC-Entwicklungsumgebung integrierten Debugger-Software. Üblicherweise besteht diese Software aus mehreren Fenstern zur Anzeige folgender Informationen:

  • Programm- und Datenspeicher des Mikrocontrollers.
  • Arbeits- und Konfigurationsregister des Mikrocontrollers.
  • Programmquellcode in Hochsprache (z. B. C) und/oder Assembler.
  • Werte von Programm-Variablen.

Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise oder wiederholend abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert. Angemerkt sei, Debugging einer Hochsprache wie C funktioniert nur richtig, wenn die Codeoptimierung des Compilers deaktiviert ist. Diese Bedingung bringt es mit sich, dass für die Entwicklungsphase bis zu 30% mehr Programmspeicher benötigt werden.

Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controllerumgebung, noch Interrupts realistisch nachahmen. Hier hilft nur In-System-Debugging direkt auf dem Zielsystem.

Für das In-System-Debugging wird der Ziel-Mikrocontroller mit seiner In-Circuit-Debugging-Hardware benutzt. Diese integrierte Hardware kommuniziert über teils genormte Schnittstellen mit der Debuggersoftware auf dem PC. Als Verbindungsglied dient ein Kabel mit mehr oder weniger komplexer Elektronik. Diese Elektronik, das fehlende Wissen um ihre Funktion und die teils eingebaute Donglefunktion verhindern preisgünstigen Nachbau und machen ihren Hersteller sicher vor unautorisierter Benutzung der Entwicklungsumgebung.

Bei der Vielzahl von Controller- und Compiler-Herstellen ist es kaum möglich, einen Überblick über die Debugger-Hardware/Software zu geben. Hier nur einige Beispiele:

Atmel

System Preis
AVR JTAG ICE Clone (wenige ATmega Typen) ~ 35€
AVR Dragon ~ 55€
AVR JTAG ICE MKII - CN ~ 85$
AVR JTAG ICE MKII / Clone ~ 280€/99$
AVR ONE! ~ 550€

AVR32 Controller (32-Bit) können mit Atmels freiem AVR32 Studio, basierend auf der Eclipse IDE, programmiert und debugt werden. Die IDE bedient sich dabei der AVR32 GNU Toolchain.

Der Debugger für AVR 8-Bit RISC Controller ist in Atmels freie AVR Studio IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR (WinAVR) und der integrierten Bibliothek AVR Libc ist Hochsprach-Entwicklung und -Debugging möglich.

Der AVR JTAG ICE Clone kann nur nachfolgende ältere ATmega Controller debuggen: ATmega16, ATmega16L, ATmega162, ATmega162L, ATmega162V, ATmega165, ATmega165V, ATmega169, ATmega169L, ATmega169V, ATmega32, ATmega32L, ATmega323, ATmega323L, ATmega64, ATmega64L, ATmega128, ATmega128L, AT90CAN128. Trotzdem ist er ein sehr wertvolles, weil günstiges Werkzeug, wenn man die Typbeschränkung akzeptieren kann.

Atmel AVR Dragon kann ATtiny, ATmega, XMega, AT32UC3x und AP7xxx programmieren und debuggen. Die drei letzt genanneten MCUs werden seit AVR Studio Version 4.18 SP1 unterstützt.

AVR JTAG ICE MKII – CN ist ein Produkt aus China mit der versprochenen Funktionalität eines originalen AVR JTAG ICE MKII von Atmel. Es besitzt eigenständige Elektronik und auch die aktualisierbare Firmware ist vom Original verschieden. Oftmals ist dieses Produkt beim nicht unbekannten Online-Auktionshaus zu finden.

Microchip

System Preis
MPLAB PICkit2 / PICkit2 Debug Express ~ 30€/55€
MPLAB PICkit3 Debug Express ~ 65€
MPLAB ICD 2 / Clone ICD2.5 / Clone ICD2 ~ 90€/40€/40€
MPLAB ICD 3 ~ 190€

Alle Typen von Microchip Debugger Hardware werden von Microchips freier MPLAB IDE unterstützt. Diese IDE kann mit C-Compilern verschiedener Hersteller zusammenarbeiten. Das Setup installiert keine Microchip C-Compiler sondern bietet als Option die C-Compiler von CCS und HI-TECH. Der CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die HI-TECH Compiler für PIC10/12/16, PIC18 und PIC32 haben, wenn sie als Freeware im ‚Lite mode’ arbeiten, eingeschränkte Codeoptimierung. Microchips C-Compiler für PIC18, PIC24, dsPIC DSCs und/oder PIC32 können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen einen Teil der Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.

Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf Eclipse basierenden, HI-TECH IDE ‚HI-TIDE 3’ unterstützt. Diese moderne IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen PIC10/12/16, PIC18 und/oder PIC32. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.

Die beiden für PICs vorhandenen IDEs von Microchip und HI-TECH bilden zusammen mit den freien C-Compilern und den preisgünstigen ICD 2 Clones eine kostengünstige Möglichkeit, PIC-Code zu erstellen und zu debuggen. Die eingeschränkte Codeoptimierung ist für Amateure verschmerzbar. Einige kleine PICs haben leider keine In-Circuit-Debugging-Hardware eingebaut. Diese PICs sind nur mit Hilfe eines kostspieligen Header Boards debugbar.

TI MSP430

System Preis
Olimex MSP430 JTAG (parallel) ~ 15€
Olimex MSP430-JTAG-TINY (USB) ~ 65€
TI-FET MSP430 USB Debugging Interface ~ 115€
TI MSP430 USB Stick Development Tool ~ 30€

Programmierung und Debugging der MSP430 erfolgt über JTAG-Schnittstelle und in neusten Varianten (MSP430F20xx, F21x2, F22xx) über ‚Spy-Bi-Wire’ (2-wire JTAG). Die ursprüngliche JTAG-Schnittstelle benötigt 4 Signalleitungen plus Reset. Bei ‚Spy-Bi-Wire’ sind die Signalleitungen auf 2 reduziert.

Jeder anwenderprogrammierbare MSP430 enthält einen Bootloader. Bei den Typenreihen MSP430F1xx, F2xx und F4xx befindet er sich im ROM. Bei den MSP430F6xx im Flash-Speicher.

TI bezeichnet die Programmier- und Debugging-Hardware als Flash Emulation Tool (FET). Es existieren die Varianten ‚Parallel Port’ und USB. Die preisgünstigen parallelen Systeme beherrschen nur JTAG. Bei den USB-Systemen ist zusätzlich ‚Spy-Bi-Wire’ implementiert, und man kann damit die Codeschutzsicherung des Mikrocontrollers auslösen.

Die Olimex Produkte entsprechen in ihrer Funktion weitestgehend den TI-Vorbildern und können mit jeder Software verwendet werden, die TI-Werkzeuge unterstützt. Kleine Abweichungen bestehen bei der Olimex Implementierung der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.

Das ‚MSP430 USB Stick Development Tool’ ist eine eigenständige Debugging-Hardware mit aufgestecktem eZ430-F2013 Zielsystem. Der Stick beherrscht aber nur ‚Spy-Bi-Wire’, wodurch die Anzahl der unterstützten Controller begrenzt ist.

Als Entwicklungsumgebung stellt TI den auf der Eclipse IDE aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version ‚CCE Core Edition’ ist dieses Paket auf 16kB Code begrenzt.

Mit der freien IDE Eclipse, dem GNU C-Compiler für MSP430, einigen Zutaten und dem Olimex Parallelport-Adapter kann man die wohl preiswerteste, unbeschränkte Entwicklungsumgebung für Mikrocontroller zusammenstellen. Es ist keine perfekte Kombination, und die Installation macht einige Mühe; im Ergebnis hat man aber eine Arbeitsplattform, einschließlich Debugger, ohne unverständliche Skripte oder kryptischen Make-Files. Über diese beiden Links

findet man zwei verschiedenartige Lösungen der Installation unter Windows. Obwohl beide Varianten auf teils verschiedene Werkzeuge zurückgreifen, sind sie kombinierbar und ergeben damit Spielraum für persönliche Vorlieben.

Zilog

System Preis
USB Smart Kabel ~ 30$
Ethernet Smart Kabel ~ 70$

Die Zilog Entwicklungssysteme ZDS II (C/ASM) für Z8 Encore!®, Z8 Encore! XP®, Z8 Encore! MC™ sowie ZNEO™ Z16F Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.

NXP

System Preis
Entwicklungskit incl. USB-JTAG/SWD Programmer & Debugger ~ 25€

Die NXP Entwicklungskits sind sehr preiswerte Kits bestehend aus einem Target und einem USB-JTAG/SWD Programmer & Debugger. Das Target kann sehr einfach vom Programmer/Debugger getrennt, und für eigene Projekte verwendet werden. Siehe dazu auch die Dokumentation von NXP zu den LPCXpresso-Entwicklungskits (PDF) und diese Beschreibung. Details zur Familie gibt es hier LPC1xxx. Der Programmer & Debugger Teil der Platine hat natürlich einen USB-Anschluß, und kann sehr leicht auf eine eigene Applikation adaptiert werden. Diese PCB arbeitet hervorragend mit der kostenlosen Entwicklungssoftware zusammen.

STM32

System Preis
STM32F4DISCOVERY Demoboard incl. USB-JTAG/SWD Programmer & Debugger ~ 9..20€

Eine Umfangreiche Übersicht über die Funktionalitäten der STM32 µC sind im Artikel STM32 beschrieben. Viele Links zu Demo-Boards, Compiler, IDE's, Debugger sind im Artikel gesammelt.
Ein µC Vergleich mit STM32 und andere sind im Artikel STM32 für Einsteiger gut zusammen gelistet.

Programmübertragung

Im Idealfall stellt sich die Frage, wie das Programm in den Mikrocontroller kommt, für den Programm-Entwickler nicht. Die Debugging-Hardware erledigt diese Aufgabe ganz unauffällig mit. Da die Umstände aber nicht immer ideal sind, muss der Entwickler manchmal auf andere Methoden zurückgreifen.

Früher wurden überwiegend teure und umständlich zu handhabende Programmiergeräte verwendet, mit deren Hilfe der Programmspeicher außerhalb des Zielsystems gefüllt wurde. Heute sind die meisten Mikrocontroller über verschiedene ISP-Schnittstellen oder über das UART ‚In-System’-programmierbar.

Die ISP-Schnittstelle ist entweder als universelle Debugging- und Programmier-Schnittstelle, z. B. JTAG, oder als dedizierte Programmier-Schnittstelle realisiert. Für den zweiten Fall benötigt man einen speziellen Programmier-Adapter den man, meistens in verschiedenen Ausführungen, kaufen oder selber bauen kann. Dazugehörig ist ein passendes Programmier-Programm für den PC. Spezialisierte Programmier-Adapter und –Programme werden auch gern in der laufenden Produktion eingesetzt.

Mikrocontroller mit integriertem Bootloader können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.

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