https://www.mikrocontroller.net/api.php?action=feedcontributions&feedformat=atom&user=SimulatorMikrocontroller.net - Benutzerbeiträge [de]2026-04-11T10:59:49ZBenutzerbeiträgeMediaWiki 1.39.7https://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=40568Entscheidung Mikrocontroller2009-11-08T22:44:39Z<p>Simulator: /* Atmel */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32, 64<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm-Variablen.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / [http://www.sureelectronics.net/goods.php?id=931 Clone]<br />
| ~ 280€/99$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren, aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.keeelectronics.com/icd25debugger.html Clone ICD2.5] / [http://www.sivava.com/MPLAB_ICD2.html Clone ICD2]<br />
| ~ 90€/40€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 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 [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 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.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚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 [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]<br />
| ~ 15€<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]<br />
| ~ 65€<br />
|-<br />
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]<br />
| ~ 115€<br />
|-<br />
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]<br />
| ~ 30€<br />
|}<br />
<br />
[http://focus.ti.com/lit/ug/slau265/slau265.pdf 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Die [http://www.olimex.com/dev/index.html 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 [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.<br />
<br />
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. <br />
<br />
Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.<br />
<br />
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<br />
<br />
* [[Eclipse und MSPGCC unter Windows]] (03/2009)<br />
* [http://matthias-hartmann.blogspot.com/ Use Eclipse and mspgcc - the easy way] (Windows 02/2009)<br />
<br />
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.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=35175Entscheidung Mikrocontroller2009-03-18T19:31:34Z<p>Simulator: /* [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
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.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/140$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚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 [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]<br />
| ~ 15€<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]<br />
| ~ 65€<br />
|-<br />
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]<br />
| ~ 115€<br />
|-<br />
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]<br />
| ~ 30€<br />
|}<br />
<br />
[http://focus.ti.com/lit/ug/slau265/slau265.pdf 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.<br />
<br />
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.<br />
<br />
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 Codeschutz Sicherung des Mikrocontrollers auslösen.<br />
<br />
Die [http://www.olimex.com/dev/index.html Olimex] Produkte entsprechen in ihrer Funktion weitestgehend den TI Vorbildern und können mit jeder, die TI Werkzeuge unterstützenden, Software verwendet werden. Kleine Abweichungen bestehen bei der [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.<br />
<br />
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. <br />
<br />
Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.<br />
<br />
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<br />
<br />
* [[Eclipse und MSPGCC unter Windows]] (03/2009)<br />
* [http://matthias-hartmann.blogspot.com/ Use Eclipse and mspgcc - the easy way] (Windows 02/2009)<br />
<br />
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.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Eclipse_und_MSPGCC_unter_Windows&diff=35162Eclipse und MSPGCC unter Windows2009-03-18T11:35:28Z<p>Simulator: </p>
<hr />
<div>= Einleitung =<br />
Die Zusammenstellung eines freien Entwicklungs- und Debugging-Pakets für Mikrocontroller der MSP430 Reihe ist zum jetzigen Zeitpunkt, 03/2009, nicht ganz einfach. Es existieren mehrere Möglichkeiten des Aufbaus der Werkzeugkette, perfekt ist aber keine. Über diesen [http://matthias-hartmann.blogspot.com/ Link] findet man eine gute englischsprachige Beschreibung unter Verwendung von Eclipse, Zylin Embedded CDT, MSPGCC und MinGW.<br />
<br />
Im Unterschied dazu beruht die hier beschriebene Kombination auf Eclipse, einem Plugin zur Parametrierung ([http://homepage.hispeed.ch/py430/mspgcc/ net.sf.mspgcc.zip]) und [[MSPGCC]]. Zwischen PC und Zielsystem wird der [http://www.olimex.com/ Olimex] Parallelport-Adapter ‚MSP430-JTAG’ verwendet. Hinweise zur Nutzung des USB-Adapters ‚MSP430-JTAG-TINY’ findet man [http://www.cognimed.de/de/ueberuns/blauzahn/msp430_projekt.htm hier].<br />
<br />
= Download =<br />
Folgende Software-Komponenten sind für die Installation notwendig und über nachfolge Links verfügbar:<br />
<br />
* [http://downloads.sourceforge.net/mspgcc/mspgcc-20060502.exe?use_mirror=mesh ‚mspgcc-win32’ in der veralteten Version mspgcc-20060502.exe]<br />
* [http://sourceforge.net/project/showfiles.php?group_id=42303&package_id=68584 ‚mspgcc-win32’ in der aktuellen Version mspgcc-????????.exe]<br />
* [http://www.eclipse.org/downloads/ Eclipse Package ‚Eclipse IDE for C/C++ Developers’ (Windows)]<br />
* [http://homepage.hispeed.ch/py430/mspgcc/net.sf.mspgcc.zip Plugin für Eclipse zur Parametrierung von MSPGCC (net.sf.mspgcc.zip)]<br />
* [http://www.mikrocontroller.net/wikifiles/8/8e/MSP430.Test.zip MSP430.Test.zip] mit gdb-target.ini, main.c und main.cpp<br />
<br />
= Installation =<br />
Die nachfolgenden Bilder zeigen als Laufwerk oftmals D:. Diese Bezeichnung muss entsprechend ihren lokalen Verhältnisse anpasst werden (C:).<br />
<br />
== Parallelport-Adapter ‚MSP430-JTAG’ ==<br />
Der Systemservice-Treiber GiveIO für diesen Adapter ist im MSPGCC Setup enthalten und wird dort automatisch mit installiert. Er bewerkstelligt die Hardware-Ansteuerung der PC-Parallelschnittstelle.<br />
<br />
== GNU C-Compiler für MSP430 ==<br />
Zuerst müssen wir die alte Version mspgcc-20060502.exe vollständig installieren. Bei der Installation sollte der Pfad auf C:\Programme\mspgcc geändert werden. Ist dieses erledigt kopieren wir die Datei C:\Programme\mspgcc\bin\msp430-gdbproxy.exe an einen sicheren Platz und deinstallieren nachfolgend das ganze MSPGCC Paket wieder.<br />
<br />
Als nächstes installieren wir in gleicher Weise die aktuelle Version des MSPGCC. Da die jetzt installierte neue Datei C:\Programme\mspgcc\bin\msp430-gdbproxy.exe kein richtig funktionierendes Debugging zulässt überschreiben wir sie mit der vorher gesicherten alten Version.<br />
<br />
== Eclipse IDE und Plugin ==<br />
Von den vorbereiteten ‚Eclipse Packages’ das Paket ‚Eclipse IDE for C/C++ Developers’ (Windows) downloaden. Den Inhalt der zip-Datei nach C:\Programme extrahieren. Es entsteht der neue Ordner C:\Programme\eclipse.<br />
<br />
Die Spezialisierung der IDE Eclipse auf MSPGCC erfolgt mittels Plugins. Den Inhalt der Datei net.sf.mspgcc.zip in den Ordner C:\Programme\eclipse extrahieren. Der Inhalt des ‚plugins’ Ordners der zip-Datei wird dabei nach C:\Programme\eclipse\plugins kopiert und vereinigt sich mit diesem.<br />
<br />
Jetzt sind alle notwendigen Programme installiert, aber vor dem ersten Start von Eclipse ist noch etwas Feinarbeit zu leisten. Zuerst legen wir in unserem Arbeitsbereich auf der Festplatte einen neuen Ordner zur Aufnahme der Eclipse Konfigurationsdaten und aller zukünftigen MSP430 Entwicklungsprojekte an. Zusätzlich einen Ordner für unser erstes Test-Projekt. Die Namen der zwei Ordner sind frei und nachfolgendes ist nur ein Beispiel:<br />
<br />
* …\Dateien von User\MSP430<br />
* …\Dateien von User\MSP430\Test<br />
<br />
Aus der Datei ‚MSP430.Test.zip’ kopieren wir gdb-target.ini nach …\MSP430 und main.c oder main.cpp nach …\MSP430\Test. Die Auswahl der main Datei richtet sich danach, ob wir in C oder C++ programmieren wollen.<br />
<br />
Nun können wir das Programm C:\Programme\eclipse\eclipse.exe erstmalig starten. Sollte eine Fehlermeldung das [http://java.sun.com/javase/downloads/ ‚Java SE Runtime Environment (JRE)’] verlangen, dann dieses zusätzlich downloaden und installieren. Eclipse möchte nach dem ersten Start sofort eine Ordner zum speichern der Konfiguration und zukünftiger Projekte anlegen. Ändern sie den vorgeschlagenen Pfad so, dass er auf unseren neuen Ordner ‚…\MSP430’ zeigt.<br />
<br />
= Konfiguration =<br />
Zur Konfiguration der Eclipse IDE gehören persönliche Einstellungen, der Debugger Proxy als Bindeglied zur Adapter-Hardware und der Debugger selbst.<br />
<br />
== Konfiguration General ==<br />
Als erste Konfiguration ist es vorteilhaft die IDE über ‚Window – Preferences’ an persönliche Vorlieben anzupassen. Unter ‚General – Keys’ ist das die Festlegung von Kurzwahltasten, unter ‚General – Workspace’ das automatische Kompilieren bzw. Speichern und unter ‚C/C++ - Code Style’ das Profil zur automatischen Formatierung des C-Quelltexts.<br />
<br />
[[Bild:MspEclipse01.png]]<br />
<br />
== Konfiguration Debugger Proxy ==<br />
Im nächsten Schritt parametrieren und starten wir über ‚Run – External Tools – External Tools Configuratations…’ den MSP430-GDBProxy. Gleichzeitig wird dadurch ein neuer Menüeintrag erzeugt worüber dieses Hintergrund-Programm späterhin, jeweils einmalig vor jeder Sitzung, gestartet wird.<br />
<br />
[[Bild:MspEclipse02.png]]<br />
<br />
* MSP430-GDBProxy<br />
* Argumente für Parallel Adapter: --port=3333 msp430<br />
* Argumente für USB Adapter: --port=3333 msp430 TIUSB<br />
* Argumente für USB (Spy-Bi-Wire): --port=3333 msp430 --spy-bi-wire TIUSB<br />
<br />
== Konfiguration Debugger ==<br />
Die IDE Eclipse ist so strukturiert, dass man für jedes Projekt die Konfiguration des Debuggers neu vornehmen muss. Um das zu vereinfachen legen wir ein Debugger-Template an von dem wir später, für jedes neue Projekt, ein Duplikat erzeugen. Das offene Feld ‚Project’ wird später im Duplikat ausgefüllt.<br />
<br />
[[Bild:MspEclipse03.png]]<br />
<br />
* Debug/Executable.elf<br />
* msp430-gdb<br />
* gdb-target.ini<br />
* 3333 <br />
<br />
= Erstes Projekt =<br />
Jetzt ist es an der Zeit das erste Test-Projekt zu konfigurieren. Der Projekttyp sollte dem Typ der main Datei entsprechen und der Projektname so lauten wie der Projektordner. Günstig ist es, entgegen dem hier gezeigten Vorgehen, die Konfigurationen Debug und Release gleichzeitig anzulegen. Dieses ist aber auch nachträglich möglich. Die detaillierten Einstellungen zum Kompilieren und Linken werden nach Betätigen von ‚Advanced settings…’ festgelegt.<br />
<br />
[[Bild:MspEclipse04.png]]<br />
<br />
Nachfolgende Einstellungen sind für C und C++ Projekte identisch. Ab dem nächsten Abschnitt folgen dann die Spezialitäten für C und C++.<br />
<br />
[[Bild:MspEclipse05.png]]<br />
<br />
* Der interne Builder ist schneller, erzeugt weniger Zwischendateien und die Consolen-Ausgabe ist kompakter.<br />
* C Projekt: msp430-gcc<br />
* C++ Projekt: msp430-g++<br />
<br />
[[Bild:MspEclipse06.png]] <br />
<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
*: msp430x???? <br />
<br />
[[Bild:MspEclipse07.png]]<br />
<br />
* Der Post-build Step dient zur Anzeige der Binärcode Größe:<br />
*: msp430-size --format=sysv --radix=16 --target=elf32-msp430 Executable.elf <br />
* Die Artefact Bezeichnung ist gleich der Einstellung im Debugger Template:<br />
*: Executable<br />
*: elf<br />
<br />
== C Projekt ==<br />
<br />
Die jetzt folgenden Einstellungen gelten nur für C Projekte. Alle speziellen Konfigurationen für C++ Projekte befinden sich einen Abschnitt tiefer.<br />
<br />
[[Bild:MspEclipse08.png]]<br />
<br />
* Diese Flags sind nicht notwendig aber empfehlenswert:<br />
*: -fshort-enums -fsigned-char -mendup-at=main<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
*: msp430x???? <br />
<br />
[[Bild:MspEclipse09.png]]<br />
<br />
* Es schadet nichts dem Linker die Mathematik-Library mit den Gleitkomma-Funktionen bekannt zu machen. <br />
<br />
== C++ Projekt ==<br />
<br />
Die jetzt folgenden Einstellungen gelten nur für C++ Projekte. Alle speziellen Konfigurationen für C Projekte befinden sich einen Abschnitt höher.<br />
<br />
[[Bild:MspEclipse10.png]]<br />
<br />
* Diese Flags sind nicht notwendig aber empfehlenswert:<br />
*: -fshort-enums -fsigned-char -mendup-at=main -fno-rtti<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
*: msp430x???? <br />
* Weil der MSPGCC keine C++ Standardlibrary beinhaltet, der Linker diese aber laden will, müssen wir das unterbinden.<br />
<br />
[[Bild:MspEclipse11.png]]<br />
<br />
* Da die C++ Standardlibrary nicht existiert linken wir mit den C Librarys. ‚gcc’ muss als Letztes stehen.<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
*: -mmcu=msp430x????<br />
<br />
== Kompilieren ==<br />
Auch wenn dem Test-Projekt noch keine Debugger-Konfiguration zugewiesen ist, können wir jetzt den ersten Build-Vorgang starten.<br />
<br />
[[Bild:MspEclipse12.png]]<br />
<br />
Nach Durchlauf ist das untere Eclipse-Fenster ‚Console’ interessant. Es zeigt eventuelle Fehlermeldungen von Compiler oder Linker. Ist kein Fehler aufgetreten, so hat der Linker die Datei …\Test\Debug\Executable.elf erzeugt.<br />
<br />
== Debugging ==<br />
Zunächst öffnen wir durch Doppelklick die Datei main.c oder main.cpp und wechseln zusätzlich in die andere Eclipse Ansicht ‚Debug Perspective’. Links oben im Fenster Debug sollte die Bestätigung des aktiven Debugger Proxy msp430-gdb sichtbar sein. Wenn nicht starten wir ihn über das Menü ‚Run – External Tools – MSP430-GDB-Proxy’.<br />
<br />
[[Bild:MspEclipse13.png]]<br />
<br />
Vor dem Debugging muss unserem Projekt nun einmalig die Debugger Konfiguration zugewiesen werden. Dazu duplizieren wir das bereits angelegte Debug Template, vergeben einen Namen für die Kopie und weisen der Kopie das Projekt Test zu.<br />
<br />
[[Bild:MspEclipse14.png]]<br />
<br />
Danach drücken wir ‚Debug’ und beobachten in den Fenstern Debug und Console wie Eclipse unser Anwenderprogramm auf das Zielsystem lädt und die Debugging Sitzung eröffnet. Der Programmlauf stoppt selbsttätig am Beginn der Funktion main() und wir sehen die erste Programmzeile von main() markiert.<br />
<br />
Der eigentliche Debugging Vorgang entspricht nun dem Üblichen und interessant ist mehr was nicht funktioniert.<br />
<br />
Zunächst ist das der Befehl ‚Step over’. Er wird immer als ‚Step into’ ausgeführt. Um langwieriges Durchsteppen von Funktionsaufrufen zu vermeiden muss man deshalb den Befehl ‚Run to Line’ benutzen.<br />
<br />
Im Weiteren funktioniert der Befehl ‚Restart’ nicht. Es ist also notwendig mit ‚Terminate’ zu beenden und danach eine neue Debugging Sitzung zu beginnen.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Eclipse_und_MSPGCC_unter_Windows&diff=35160Eclipse und MSPGCC unter Windows2009-03-17T22:27:59Z<p>Simulator: </p>
<hr />
<div>= Einleitung =<br />
Die Zusammenstellung eines freien Entwicklungs- und Debugging-Pakets für Mikrocontroller der MSP430 Reihe ist zum jetzigen Zeitpunkt, 03/2009, nicht ganz einfach. Es existieren mehrere Möglichkeiten des Aufbaus der Werkzeugkette, perfekt ist aber keine. Unter diesem [http://matthias-hartmann.blogspot.com/ Link] findet man eine gute englischsprachige Beschreibung unter Verwendung von Eclipse, Zylin Embedded CDT, MSPGCC und MinGW.<br />
<br />
Im Unterschied dazu beruht die hier beschriebene Kombination auf Eclipse, einem Plugin zur Parametrierung ([http://homepage.hispeed.ch/py430/mspgcc/ net.sf.mspgcc.zip]) und [[MSPGCC]]. Zwischen PC und Zielsystem wird der [http://www.olimex.com/ Olimex] Parallelport-Adapter ‚MSP430-JTAG’ verwendet. Hinweise zur Nutzung des USB-Adapters ‚MSP430-JTAG-TINY’ findet man [http://www.cognimed.de/de/ueberuns/blauzahn/msp430_projekt.htm hier].<br />
<br />
= Download =<br />
Folgende Software-Komponenten sind für die Installation notwendig und über nachfolge Links verfügbar:<br />
<br />
* [http://downloads.sourceforge.net/mspgcc/mspgcc-20060502.exe?use_mirror=mesh ‚mspgcc-win32’ in der veralteten Version mspgcc-20060502.exe]<br />
* [http://mspgcc.sourceforge.net/ ‚mspgcc-win32’ in der aktuellen Version mspgcc-????????.exe]<br />
* [http://www.eclipse.org/downloads/ Eclipse Package ‚Eclipse IDE for C/C++ Developers’ (Windows)]<br />
* [http://homepage.hispeed.ch/py430/mspgcc/net.sf.mspgcc.zip Plugin für Eclipse zur Parametrierung von MSPGCC (net.sf.mspgcc.zip)]<br />
* [http://www.mikrocontroller.net/wikifiles/8/8e/MSP430.Test.zip MSP430.Test.zip] mit gdb-target.ini, main.c und main.cpp<br />
<br />
= Installation =<br />
Die nachfolgenden Bilder zeigen als Laufwerk oftmals D:. Diese Bezeichnung muss entsprechend ihren lokalen Verhältnisse anpasst werden (C:).<br />
<br />
== Parallelport-Adapter ‚MSP430-JTAG’ ==<br />
Der Systemservice-Treiber GiveIO für diesen Adapter ist im MSPGCC Setup enthalten und wird dort automatisch mit installiert. Er bewerkstelligt die Hardware-Ansteuerung der PC-Parallelschnittstelle.<br />
<br />
== GNU C-Compiler für MSP430 ==<br />
Zuerst müssen wir die alte Version mspgcc-20060502.exe vollständig installieren. Bei der Installation sollte der Pfad auf C:\Programme\mspgcc geändert werden. Ist dieses erledigt kopieren wir die Datei C:\Programme\mspgcc\bin\msp430-gdbproxy.exe an einen sicheren Platz und deinstallieren nachfolgend das ganze MSPGCC Paket wieder.<br />
<br />
Als nächstes installieren wir in gleicher Weise die aktuelle Version des MSPGCC. Da die jetzt installierte neue Datei C:\Programme\mspgcc\bin\msp430-gdbproxy.exe kein richtig funktionierendes Debugging zulässt überschreiben wir sie mit der vorher gesicherten alten Version.<br />
<br />
== Eclipse IDE und Plugin ==<br />
Von den vorbereiteten ‚Eclipse Packages’ das Paket ‚Eclipse IDE for C/C++ Developers’ (Windows) downloaden. Den Inhalt der zip-Datei nach C:\Programme extrahieren. Es entsteht der neue Ordner C:\Programme\eclipse.<br />
<br />
Die Spezialisierung der IDE Eclipse auf MSPGCC erfolgt mittels Plugins. Den Inhalt der Datei net.sf.mspgcc.zip in den Ordner C:\Programme\eclipse extrahieren. Der Inhalt des ‚plugins’ Ordners der zip-Datei wird dabei nach C:\Programme\eclipse\plugins kopiert und vereinigt sich mit diesem.<br />
<br />
Jetzt sind alle notwendigen Programme installiert, aber vor dem ersten Start von Eclipse ist noch etwas Feinarbeit zu leisten. Zuerst legen wir in unserem Arbeitsbereich auf der Festplatte einen neuen Ordner zur Aufnahme der Eclipse Konfigurationsdaten und aller zukünftigen MSP430 Entwicklungsprojekte an. Zusätzlich einen Ordner für unser erstes Test-Projekt. Die Namen der zwei Ordner sind frei und nachfolgendes ist nur ein Beispiel:<br />
<br />
* …\Dateien von User\MSP430<br />
* …\Dateien von User\MSP430\Test<br />
<br />
Aus der Datei ‚MSP430.Test.zip’ kopieren wir gdb-target.ini nach …\MSP430 und main.c oder main.cpp nach …\MSP430\Test. Die Auswahl der main Datei richtet sich danach, ob wir in C oder C++ programmieren wollen.<br />
<br />
Nun können wir das Programm C:\Programme\eclipse\eclipse.exe erstmalig starten. Sollte eine Fehlermeldung das [http://java.sun.com/javase/downloads/ ‚Java SE Runtime Environment (JRE)’] verlangen, dann dieses zusätzlich downloaden und installieren. Eclipse möchte nach dem ersten Start sofort eine Ordner zum speichern der Konfiguration und zukünftiger Projekte anlegen. Ändern sie den vorgeschlagenen Pfad so, dass er auf unseren neuen Ordner ‚…\MSP430’ zeigt.<br />
<br />
= Konfiguration =<br />
Zur Konfiguration der Eclipse IDE gehören persönliche Einstellungen, der Debugger Proxy als Bindeglied zur Adapter-Hardware und der Debugger selbst.<br />
<br />
== Konfiguration General ==<br />
Als erste Konfiguration ist es vorteilhaft die IDE über ‚Window – Preferences’ an persönliche Vorlieben anzupassen. Unter ‚General – Keys’ ist das die Festlegung von Kurzwahltasten, unter ‚General – Workspace’ das automatische Kompilieren bzw. Speichern und unter ‚C/C++ - Code Style’ das Profil zur automatischen Formatierung des C-Quelltexts.<br />
<br />
[[Bild:MspEclipse01.png]]<br />
<br />
== Konfiguration Debugger Proxy ==<br />
Im nächsten Schritt parametrieren und starten wir über ‚Run – External Tools – External Tools Configuratations…’ den MSP430-GDBProxy. Gleichzeitig wird dadurch ein neuer Menüeintrag erzeugt worüber dieses Hintergrund-Programm späterhin, jeweils einmalig vor jeder Sitzung, gestartet wird.<br />
<br />
[[Bild:MspEclipse02.png]]<br />
<br />
* MSP430-GDBProxy<br />
* Argumente für Parallel Adapter: --port=3333 msp430<br />
* Argumente für USB Adapter: --port=3333 msp430 TIUSB<br />
* Argumente für USB (Spy-Bi-Wire): --port=3333 msp430 --spy-bi-wire TIUSB<br />
<br />
== Konfiguration Debugger ==<br />
Die IDE Eclipse ist so strukturiert, dass man für jedes Projekt die Konfiguration des Debuggers neu vornehmen muss. Um das zu vereinfachen legen wir ein Debugger-Template an von dem wir später, für jedes neue Projekt, ein Duplikat erzeugen. Das offene Feld ‚Project’ wird später im Duplikat ausgefüllt.<br />
<br />
[[Bild:MspEclipse03.png]]<br />
<br />
* Debug/Executable.elf<br />
* msp430-gdb<br />
* gdb-target.ini<br />
* 3333 <br />
<br />
= Erstes Projekt =<br />
Jetzt ist es an der Zeit das erste Test-Projekt zu konfigurieren. Der Projekttyp sollte dem Typ der main Datei entsprechen und der Projektname so lauten wie der Projektordner. Günstig ist es, entgegen dem hier gezeigten Vorgehen, die Konfigurationen Debug und Release gleichzeitig anzulegen. Dieses ist aber auch nachträglich möglich. Die detaillierten Einstellungen zum Kompilieren und Linken werden nach Betätigen von ‚Advanced settings…’ festgelegt.<br />
<br />
[[Bild:MspEclipse04.png]]<br />
<br />
Nachfolgende Einstellungen sind für C und C++ Projekte identisch. Ab dem nächsten Abschnitt folgen dann die Spezialitäten für C und C++.<br />
<br />
[[Bild:MspEclipse05.png]]<br />
<br />
* Der interne Builder ist schneller, erzeugt weniger Zwischendateien und die Consolen-Ausgabe ist kompakter.<br />
* C Projekt: msp430-gcc<br />
* C++ Projekt: msp430-g++<br />
<br />
[[Bild:MspEclipse06.png]] <br />
<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* msp430x???? <br />
<br />
[[Bild:MspEclipse07.png]]<br />
<br />
* Der Post-build Step dient zur Anzeige der Binärcode Größe.<br />
* msp430-size --format=sysv --radix=16 --target=elf32-msp430 Executable.elf <br />
* Die Artefact Bezeichnung ist gleich der Einstellung im Debugger Template.<br />
* Executable<br />
* elf<br />
<br />
== C Projekt ==<br />
<br />
[[Bild:MspEclipse08.png]]<br />
<br />
* Diese Flags sind nicht notwendig aber empfehlenswert: -fshort-enums -fsigned-char -mendup-at=main<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* msp430x???? <br />
<br />
[[Bild:MspEclipse09.png]]<br />
<br />
* Es schadet nichts dem Linker die Mathematik-Library mit den Gleitkomma-Funktionen bekannt zu machen. <br />
<br />
== C++ Projekt ==<br />
<br />
[[Bild:MspEclipse10.png]]<br />
<br />
* Diese Flags sind nicht notwendig aber empfehlenswert: -fshort-enums -fsigned-char -mendup-at=main -fno-rtti<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* msp430x???? <br />
* Weil der MSPGCC keine C++ Standardlibrary beinhaltet, der Linker diese aber laden will, müssen wir das unterbinden.<br />
<br />
[[Bild:MspEclipse11.png]]<br />
<br />
* Da die C++ Standardlibrary nicht existiert linken wir mit den C Librarys. ‚gcc’ muss als Letztes stehen.<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* -mmcu=msp430x????<br />
<br />
== Kompilieren ==<br />
Auch wenn dem Test-Projekt noch keine Debugger-Konfiguration zugewiesen ist, können wir jetzt den ersten Build-Vorgang starten.<br />
<br />
[[Bild:MspEclipse12.png]]<br />
<br />
Nach Durchlauf ist das untere Eclipse-Fenster ‚Console’ interessant. Es zeigt eventuelle Fehlermeldungen von Compiler oder Linker. Ist kein Fehler aufgetreten, so hat der Linker die Datei …\Test\Debug\Executable.elf erzeugt.<br />
<br />
== Debugging ==<br />
Zunächst öffnen wir durch Doppelklick die Datei main.c oder main.cpp und wechseln zusätzlich in die andere Eclipse Ansicht ‚Debug Perspective’. Links oben im Fenster Debug sollte die Bestätigung des aktiven Debugger Proxy msp430-gdb sichtbar sein. Wenn nicht starten wir ihn über das Menü ‚Run – External Tools – MSP430-GDB-Proxy’.<br />
<br />
[[Bild:MspEclipse13.png]]<br />
<br />
Vor dem Debugging muss unserem Projekt nun einmalig die Debugger Konfiguration zugewiesen werden. Dazu duplizieren wir das bereits angelegte Debug Template, vergeben einen Namen für die Kopie und weisen der Kopie das Projekt Test zu.<br />
<br />
[[Bild:MspEclipse14.png]]<br />
<br />
Danach drücken wir ‚Debug’ und beobachten in den Fenstern Debug und Console wie Eclipse unser Anwenderprogramm auf das Zielsystem lädt und die Debugging Sitzung eröffnet. Der Programmlauf stoppt selbsttätig am Beginn der Funktion main() und wir sehen die erste Programmzeile vom main() markiert.<br />
<br />
Der eigentliche Debugging Vorgang entspricht nun dem Üblichen und interessant ist mehr was nicht funktioniert.<br />
<br />
Zunächst ist das der Befehl ‚Step over’. Er wird immer als ‚Step into’ ausgeführt. Um langwieriges Durchsteppen von Funktionsaufrufen zu vermeiden muss man deshalb den Befehl ‚Run to Line’ benutzen.<br />
<br />
Im Weiteren funktioniert der Befehl ‚Restart’ nicht. Es ist also notwendig mit ‚Terminate’ zu beenden und danach eine neue Debugging Sitzung zu beginnen.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=MSP430&diff=35159MSP4302009-03-17T21:40:19Z<p>Simulator: /* MSPGCC */</p>
<hr />
<div>== Einleitung ==<br />
<br />
Der MSP430 ist ein 16 Bit-Mikrocontroller von Texas Instruments (TI). Er wurde speziell für eine geringe Stromaufnahme entwickelt, so dass er besonders für batteriebetriebene Geräte geeignet ist. Es gibt verschiedene Typen mit 1-256 kB [[Flash-ROM]], 128-16384 Byte [[RAM]], teilweise mit Hardware-Multiplizierer, [[UART]], [[AD-Wandler]] oder LCD-Treiber, die meisten im [[SMD]]-Package mit 20 bis >100 Pins. Einige neuere aus der MSP430F2xxx-Serie gibt es auch im DIP-Package (Bezeichnung: MSPxxxx '''-N'''). Der MSP430F1121 zum Beispiel hat 4kB [[Flash-ROM]], 256B [[RAM]], 2 [[Timer]] und steckt in einem SO-20 Gehäuse. Seit dem Shrinking Ende 2008 gibt es einige Typen der Reihe MSP430X5xx mit integriertem USB-Controller (slave), RF-Transceiver, LDO-Spannungsregler und einer AES-Cryptoengine.<br />
<br />
== Entwicklungshardware ==<br />
Für den schnellen Einstieg stellt TI ein preisgünstiges Entwicklungssystem mit USB Schnittstelle zur Verfügung. ([http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool])<br />
<br />
Günstige Adapterplatinen und [[JTAG]]-Programmer für MSP430-Controller bekommt man bei [http://olimex.com/dev/ Olimex (Bulgarien)], in Deutschland bei http://shop.mikrocontroller.net und http://www.elektronikladen.de oder in Japan bei [http://passworld.co.jp/index.php?lang=GB&lieu=Soroban PassWorld].<br />
<br />
Einen einfachen Schaltplan für den [[JTAG]]-Programmer von TI bzw. Olimex gibt es [[Media:MSP430-JTAG-programmer.pdf|hier]]. Die Spannungsversorgung kommt im Gegensatz zum Original allerdings nicht vom Drucker-Port sondern muss extern (am besten vom MSP430 Board) bereitgestellt werden.<br />
<br />
Neben der JTAG-Programmierung bieten die MSP430-Controller auch die Möglichkeit, die Firmware über einen [[Bootloader]] einzuspielen. Die dafür erforderliche Hardware wird in der Application Note [http://focus.ti.com/docs/mcu/catalog/resources/appnoteabstract.jhtml?familyId=342&abstractName=slaa096d SLAA096d] von Texas Instruments beschrieben.<br />
<br />
=== Stromversorgung ===<br />
<br />
Der MSP430 benötigt eine Spannung zwischen 1,8 und 3,6 V. Einfach erzeugen kann man diese z.B. mit der folgenden Schaltung:<br />
<br />
http://www.mikrocontroller.net/images/lm317.png<br />
<br />
An den Eingang wird ein Steckernetzteil angeschlossen, die Ausgangsspannung lässt sich über das Potentiometer P1 einstellen.<br />
Benutzt man für P1 einen 500-Ohm-Typ, kann man die Spannung in einem Bereich von 1,2 Volt und knapp 3,6 Volt einstellen. Dann kann man den MSP430 nicht durch zu hohe Verorgungsspannungen zerstören.<br />
Einige neuere Typen der Reihe MSP430F5xx bieten einen integrierten Low-Drop-Spannungsregler an.<br />
<br />
== Dokumentation ==<br />
<br />
* TI's Website: http://www.msp430.com <br />
*:Für jede MSP430 Familie (z.B. MSP430F1xxx) gibt es ein generelles "datasheet" und einen detailierten "user guide". Die im user guide verwendeten Registerbezeichnungen (Ports, SFRs, etc.) findet man auch bei den meisten Compilern wieder.<br />
<br />
* Buch: Mikrocontrollertechnik Am Beispiel der MSP430-Familie<br />
*:Dieses Lehrbuch führt in die Grundlagen der Mikrorechentechnik ein. Es beschreibt sehr detailliert den Aufbau, die Funktion und die Handhabung von Mikrocontrollern am Beispiel des MSP430F1232. Programmbeispiele sind in Assembler und C enthalten. Ideal für Einsteiger mit geringen technischen Vorkenntnissen. Autor: Matthias Sturm ISBN:3-446-21800-9, Hanser Verlag<br />
<br />
== Software ==<br />
===Freie Tools===<br />
====MSP-CCE430====<br />
Dies ist die Entwicklungsumgebung von TI. Es gibt eine teure Pro-Version, aber eben auch eine Freeware-Version, die auf 16kB Codegrösse beschränkt ist. <br />
<br />
Dieser Entwicklungsumgebung liegt Eclipse zugrunde, wobei der C-Compiler und ein Debugger bereits eingebunden sind. Die Installation ist im Gegensatz zu MSPGCC kein Problem.<br />
<br />
* [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html Download MSP-CCE430]<br />
<br />
====MSPGCC====<br />
Man kann Programme für den MSP430 komplett mit freien Tools entwickeln. Mit dem C-Compiler [[MSPGCC]], dem Debugging-Programm [[GDB]]/Insight und einem beliebigen [[Texteditor]] kann man C-Programme schreiben, kompilieren, in den Controller programmieren und debuggen. In Kombination mit MSPGCC kann man auch die freie Entwicklungsumgebung Eclipse verwenden.<br />
<br />
Weblinks:<br />
* [http://www.mikrocontroller.net/articles/Eclipse_und_MSPGCC_unter_Windows Eclipse und MSPGCC unter Windows] (03/2009)<br />
* [http://matthias-hartmann.blogspot.com/ Use Eclipse and mspgcc - the easy way] (Windows 02/2009).<br />
* [http://www.mikrocontroller.net/Eclipse%20und%20MSPGCC/ Eclipse und MSPGCC] (03/2006)<br />
* [http://inf.ntb.ch/infoportal/help/index.jsp?topic=/ch.ntb.infoportal/embeddedSystems_MSP430.html/ Eclipse + MSPGCC + Installationsanleitung Deutsch] (Windows, Linux)<br />
<br />
* [http://kurt.on.ufanet.ru/ MSPFET - FREE MSP430 flash programming utility] (Windows)<br />
<br />
=== Kommerzielle Compiler für MSP430 ===<br />
* [http://www.imagecraft.com/devtools_MSP430.html ICC430]<br />
*: 45-Tage Demo wird nach Ablauf auf 4 kByte Codegröße beschränkt<br />
* [http://www.htsoft.com/products/msp430ccompiler.php HI-TECH MSP430 C]<br />
*: 28-Tage Demo wird nach Ablauf unbrauchbar<br />
* [http://www.ide430.com/ IDE430]<br />
*: ''Dieser Link ist tot. Gibt es das Produkt noch?''<br />
* [http://www.rowley.co.uk/msp430/index.htm CrossWorks for MSP430]<br />
*: 30-Tage-Testversion nach Registrierung<br />
* [http://www.quadravox.com/AQ430.htm Quadravox AQ430]<br />
* [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html?DCMP=MSP430_ccessentials&HQS=Other+PR+ccessentials CCEssentials (Eclipse)]<br />
*: Frei und auf 8 kByte Codegröße beschränkt, seit V3 bis 16kByte Code frei<br />
* [http://www.iar.se/website1/1.0.1.0/675/1/index.php IAR Embedded Workbench for MSP430] <br />
*: 30-Tage-Testversion<br />
*: Freie auf 4 kByte Codegröße beschränkte "KickStart"-Edition.<br />
*: Kompatibel mit Windows7 7000 x64 (Stand: Februar 2009, Version 4.20.1)<br />
*: Nicht Windows Vista kompatibel (Stand: Mai 2008, Version 4.1A) < stimmt das noch?<br />
<br />
== Beispielanwendungen ==<br />
<br />
===Mathar.Com===<br />
Auf http://www.mathar.com gibt es ein paar Beispiele (in C), was man so alles mit dem MSP430 anstellen kann. Dort hat der Autor einige Anwendungen näher erläutert. Angefangen mit simplen Aufgaben wie LEDs leuchten lassen geht es weiter über eine LCD- und GLCD-Ansteuerung (HD44780- und KS0108-kompatibel) sowie einigen Beispielen zur Verwendung des integrierten A/D-Wandlers, des USARTs, des Timers und vielem mehr ... Als weitere Codebeispiele sind dort auch eine I2C-Softwareimplementation und eine CAN-Library für den MSP430 zu finden.<br />
<br />
===Examples Ordner der freien Toolchain MSPGCC===<br />
Der "examples"-Ordner bzw. "checkout" aus dem CVS vom [[MSPGCC]] ist auch sehr umfangreich: http://mspgcc.cvs.sourceforge.net/mspgcc/examples/<br />
<br />
===Codebeispiele auf Mikrokontroller.net===<br />
Einige [[MSP430 Codebeispiele]] finden sich auch hier in der Artikelsammlung.<br />
<br />
===uIP Port auf Mikrokontroller.net===<br />
Der Port des TCP/IP Stacks von Adam Dunkels [[MSP430_uIP_Port|uIP 1.0 für den MSP430 findet sich hier]].<br />
<br />
== Links ==<br />
<br />
* [http://www.mikrocontroller.net/forum/1/msp430 Beiträge zum MSP430 im Mikrocontroller.net Forum]<br />
* [http://mspgcc.sourceforge.net/manual/c68.html An introduction to the TI MSP430 low-power microcontrollers]<br />
* [http://tinymicros.com/embedded/MSP430/ The MSP430 Bugspray Database] - umfangreiche Datenbank für Bugs in MSP430-Controllern<br />
* [http://www.mathar.com www.mathar.com] - Tutorial für Einsteiger und Fortgeschrittene: LCD, ADC, USART, I2C, CAN Programmierung in C<br />
* [http://cnx.org/lenses/TexasInstruments/MSP430 Connexions - Texas Instruments MSP430] Tutorial (speziell für eZ430)<br />
* [http://msp430.info MSP430.info] - Portalseite für MSP430; Info, Projekte, Paper, Entwicklungstools...<br />
* [http://groups.yahoo.com/group/msp430 Yahoo group MSP430] - lebhaftes Forum mit vielen MSP430-Experten<br />
* [http://www.thomas-wedemeyer.de/elektronik/msp430/msp430.html Thomas Wedemeyer's MSP430-Seiten] - Kleine Beispiel Applikationen und Tips zur Nutzung von MSPGCC mit der Dev-C++ Entwicklungsumgebung<br />
[[Kategorie:Mikrocontroller]]<br />
* [http://homepage.hispeed.ch/py430/mspgcc/ msp430-gdb und Eclipse] - Eine Anleitung von Chris Liechti<br />
* [http://passworld.co.jp/index.php?lang=GB&lieu=GPS MSP430 GPS] - [http://passworld.co.jp/index.php?lang=GB&lieu=Oximeter MSP430 Puls-Oximeter]<br />
* [http://passworld.co.jp/ForumMSP430 MSP430 Forum]<br />
* [http://develissimo.net/de/msp430entwicklung.html MSPGCC + Eclipse + msp430-gdbproxy / Linux / Debian / Ubuntu] - Anleitung / Tutorial zur Installation der MSPGCC Toolchain + Eclipse + msp430-gdbproxy für Linux / Debian / Ubuntu Lang=Deutsch und Englisch<br />
* [http://www.sinelabore.com SinelaboreRT] - Generierung von Zustandsmaschinen in C speziell für kleine Low-Power Plattformen.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=MSPGCC&diff=35158MSPGCC2009-03-17T21:37:27Z<p>Simulator: /* Windows-Version */</p>
<hr />
<div>MSPGCC ist ein kostenloser, unbeschränkter [[C]]-[[Compiler]] für die [[MSP430]]-[[Mikrocontroller]] von [[TI]]. Die Portierung auf MSP430 wurde von Chris Liechti und Dmitry Diky durchgeführt.<br />
<br />
== Dokumentation ==<br />
<br />
* [http://mspgcc.sourceforge.net/manual/ MSPGCC Manual]<br />
* [http://mspgcc.sourceforge.net/faq/ FAQ]<br />
<br />
== Beispielprogramme ==<br />
<br />
Für MSPGCC sind umfangreiche Beispielprogramme ([[LCD]]-Ansteuerung, TCP/IP, ...) verfügbar, außerdem wurden alle TI-Appnotes (C und Assembler) von Steve Underwood für MSPGCC angepasst.<br />
<br />
* [http://mspgcc.cvs.sourceforge.net/mspgcc/examples/ MSPGCC Beispiele & Appnotes]<br />
<br />
== Windows-Version ==<br />
<br />
* [http://sourceforge.net/project/showfiles.php?group_id=42303&package_id=68584 MSPGCC Komplettpaket]<br />
<br />
* [http://www.mikrocontroller.net/articles/Eclipse_und_MSPGCC_unter_Windows Eclipse und MSPGCC unter Windows] (03/2009)<br />
* [http://matthias-hartmann.blogspot.com/ Use Eclipse and mspgcc - the easy way] (Windows 02/2009).<br />
* [http://www.mikrocontroller.net/Eclipse%20und%20MSPGCC/ ausführliche Anleitung zur Verwendung von Eclipse mit MSPGCC unter Windows] (03/2006)<br />
<br />
== Installationsanleitung für Unix/Linux/Cygwin ==<br />
<br />
<pre><br />
$ su<br />
<br />
$ mkdir /tmp/mspgcc<br />
$ cd /tmp/mspgcc<br />
</pre><br />
<br />
=== binutils ===<br />
<br />
<pre><br />
$ wget ftp://sources.redhat.com/pub/binutils/releases/binutils-2.17.tar.bz2<br />
$ tar xjvf binutils-2.17.tar.bz2<br />
<br />
$ cd binutils-2.17<br />
$ ./configure --prefix=/usr/local/msp430 --target=msp430<br />
$ make<br />
$ make install<br />
$ cd ..<br />
<br />
$ export PATH=/usr/local/msp430/bin:$PATH<br />
</pre><br />
<br />
Hinweis: Das Kommando wget setzt einen Internetzugang voraus.<br />
<br />
Hinweis2:<br> Die Version 2.14 enthält nicht alle Controllertypen. So fehlen zum Beispiel die Typen MSP430F1611 und MSP430F1612.<br><br />
Bei Version 2.17 kann es zu fehlerhaften binarys kommen (Fehler: test.elf has no bss section)<br><br />
Mit der Version 2.16.1 sollte alles funktionieren.<br />
<br />
=== gcc ===<br />
'''Achtung:''' MSPGCC kompiliert nicht gcc-4.1. Abhilfe schafft es zu Beginn (oder vor configure) den Befehl "export CC=gcc-3.3" bzw. "export CC=gcc-3.4" aufzurufen. Auch ist darauf zu achten die Dateien gcc-core-3.2.3 und gcc-g++.tar.bz2 und nicht etwa gcc-3.2.3 runterzuladen. <br />
<pre><br />
$ wget ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.2.3/gcc-core-3.2.3.tar.bz2<br />
$ wget ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.2.3/gcc-g++-3.2.3.tar.bz2<br />
$ tar xjvf gcc-core-3.2.3.tar.bz2<br />
$ tar xjvf gcc-g++-3.2.3.tar.bz2<br />
<br />
$ cvs -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc login<br />
$ cvs -z3 -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co gcc/gcc-3.3<br />
$ cp -r gcc/gcc-3.3/* gcc-3.2.3/<br />
<br />
$ cd gcc-3.2.3<br />
$ ./configure --prefix=/usr/local/msp430 --target=msp430 --enable-languages=c,c++<br />
$ make<br />
$ make install<br />
$ cd ..<br />
</pre><br />
<br />
=== msp430-libc ===<br />
<br />
<pre><br />
$ cvs -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc login<br />
$ cvs -z3 -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co msp430-libc<br />
<br />
$ cd msp430-libc/src<br />
$ make<br />
$ make install<br />
$ cd ../..<br />
</pre><br />
<br />
=== gdb ===<br />
<br />
<pre><br />
$ wget http://mirrors.redwire.net/pub/sources.redhat.com/gdb/old-releases/gdb-6.0.tar.bz2<br />
$ tar xjvf gdb-6.0.tar.bz2<br />
<br />
$ cvs -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc login<br />
$ cvs -z3 -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co gdb/gdb-current<br />
$ cp -r gdb/gdb-current/* gdb-6.0/<br />
<br />
$ cd gdb-6.0<br />
$ ./configure --prefix=/usr/local/msp430 --target=msp430<br />
$ make<br />
$ make install<br />
$ cd ..<br />
</pre><br />
<br />
Achtung: Der GDB kann nicht mit GCC 4.x übersetzt werden. Wenn dieser auf dem System standardmäßig installiert ist, kann man z.B. den GCC 3.4 zusätzlich installieren und dann vor der ./configure- Zeile<br />
<br />
<pre><br />
$ export CC=gcc-3.4<br />
</pre><br />
<br />
einfügen.<br />
<br />
Hinweis: Bei Ubuntu (evtl auch bei anderen Distributionen) sind die Entwicklerdateien für die Library libtermcap im Paket libncurses5-dev<br />
<br />
=== JTAG ===<br />
<br />
<pre><br />
$ cvs -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc login<br />
$ cvs -z3 -d:pserver:anonymous@mspgcc.cvs.sourceforge.net:/cvsroot/mspgcc co jtag<br />
<br />
$ cd jtag/hardware_access<br />
</pre><br />
<br />
Wer ein 64-Bit-Linux verwendet, muss im makefile die CFLAGS und die LNOPTS um ein -m32 ergänzen. Das sollte dann so aussehen:<br />
<br />
<pre><br />
CFLAGS += -fPIC -m32<br />
LNOPTS = -fPIC -shared -m32<br />
</pre><br />
<br />
Weiter geht's:<br />
<br />
<pre><br />
$ make<br />
$ mv libHIL.so /usr/local/lib<br />
$ ldconfig<br />
$ cd ../..<br />
</pre><br />
<br />
=== gdbproxy ===<br />
<br />
Den msp430-gdbproxy und libMSP430.so von http://www.soft-switch.org/downloads/mspgcc herunterladen. Danach<br />
<br />
<pre><br />
$ chmod +x msp430-gdbproxy<br />
$ mv msp430-gdbproxy /usr/local/msp430/bin/<br />
$ mv libMSP430.so /usr/local/lib/<br />
</pre><br />
<br />
ausführen.<br />
<br />
=== Installations-Skript ===<br />
<br />
Für Installation/Update gibt es hier ein bash-Skript, das nach dem Starten (und einmal Return zum Downloaden der Sourcen aus dem CVS) das Installieren automatisch erledigt.<br />
<br />
Eingebaut sind auch die Anpassungen von ~/.profile und ~/.gdbinit, so dass man sofort loslegen und auch debuggen kann.<br />
<br />
* [http://www.true-random.com/files/mspgcc/build_mspgcc.sh Installations-Skript]<br />
<br />
Dieses Script ist jedoch relativ veraltet. Daher ist es schneller obige Anleitung per Copy'n'Paste in eine Shell zu übernehmen, als das Script zu verwenden. <br />
<br />
=== Gentoo Ebuilds ===<br />
<br />
Für Gentoo-Benutzer gibt es an der [http://www.informatik.uni-mannheim.de/pi4/lectures/ss2004/msp430/ Uni Mannheim] Ebuilds zum Download.<br />
<br />
=== .gdbinit ===<br />
<br />
Um das JTAG-Interface schneller zu machen kann man in ~/.gdbinit diese Werte eintragen:<br />
<br />
set remoteaddresssize 16<br />
set remotetimeout 999999<br />
set download-write-size 512<br />
target remote localhost:2000<br />
set remote memory-write-packet-size 512<br />
set remote memory-write-packet-size fixed<br />
set remote memory-read-packet-size 512<br />
set remote memory-read-packet-size fixed<br />
<br />
Und vor dem Debuggen von Programmen auf dem Rechner (nicht MSP430) sollte man ~/.gdbinit umbenennen, beispielsweise in ~/.gdbinit_msp430.<br />
<br />
== Mac OS X ==<br />
<br />
Um msp430-gcc unter Mac OS X (Intel) kompilieren zu können, <br />
gcc-3.2.3/gcc/config.gcc wie folgt aendern:<br />
<br />
Von<br />
<pre><br />
i[34567]86-*-freebsd[12] | i[34567]86-*-freebsd[12].* | i[34567]86-*-freebsd*aout* )<br />
</pre><br />
<br />
auf:<br />
<pre><br />
i[34567]86-*-freebsd[12] | i[34567]86-*-freebsd[12].* | i[34567]86-*-freebsd*aout* | i[34567]86-apple-darwin8* )<br />
</pre><br />
<br />
Ansonsten die Anleitung für Linux befolgen.<br />
<br />
== Einfaches Beispielprogramm ==<br />
<br />
=== Sourcecode ===<br />
<br />
<c><br />
#include <io.h><br />
<br />
void wait(void); /* prototype for wait() */<br />
<br />
int<br />
main(void)<br />
{ /* main function, called by startup-code */<br />
P1DIR = 0xFF; /* port 1 = output */<br />
P1OUT = 0x01; /* set bit 0 in port 1 */<br />
<br />
for(;;)<br />
{ /* infinite loop */<br />
P1OUT = ~P1OUT; /* invert port 1 */<br />
wait(); /* call delay function */<br />
}<br />
}<br />
<br />
void<br />
wait(void)<br />
{ /* simple delay function */<br />
volatile int i; /* declare i as volatile int */<br />
for(i = 0; i < 32000; i++)<br />
; /* repeat 32000 times (nop) */<br />
}<br />
</c><br />
<br />
=== Sourcecode für msp430x1121 kompilieren ===<br />
<br />
$ msp430-gcc -Os -mmcu=msp430x1121 -o test.elf test.c<br />
<br />
=== Sourcecode für msp430x1121 kompilieren, wenn math.h includiert wird ===<br />
<br />
msp430-gcc -Os -mmcu=msp430x1121 -o test.elf test.c -lm<br />
<br />
Wichtig ist hierbei -lm als letzte Option.<br />
<br />
=== Assemblerlisting erzeugen (optional) ===<br />
<br />
$ msp430-objdump -DS test.elf > test.lst<br />
<br />
=== Hex-Datei erzeugen ===<br />
<br />
$ msp430-objcopy -O ihex test.elf test.hex<br />
<br />
Die Hex-Datei kann man mit C-Spy (im Kickstart-Paket enthalten) über das JTAG-Interface in den Controller programmieren. Nach einem Klick auf "Go" läuft das Programm los. Wenn 2 LEDs an P1.0 und P1.1 angeschlossen sind, sollten sie nun blinken.<br />
<br />
== In-System-Debugging mit GDB/Insight und dem Flash Emulation Tool (FET) ==<br />
<br />
Wie bei anderen MSP430-Compilern ist es möglich mspgcc-Programme direkt in der Schaltung zu debuggen. Alles was man dazu braucht, ist ein JTAG-Adapter, mdp430-gdbproxy, und gdb (im aktuellen Windows-Paket bereits enthalten).<br />
<br />
Um ein Programm mit GDB/Insight debuggen zu können, muss man die Option "-g" an den mspgcc-Aufruf anhängen:<br />
<br />
$ msp430-gcc -mmcu=msp430x123 -g -Os -o test.elf test.c<br />
<br />
Damit erhält man die Datei "test.elf".<br />
<br />
=== gdbproxy starten ===<br />
<br />
Der nächste Schritt ist das Programm gdbproxy zu starten, das für die Kommunikation zwischen GDB und dem FET zuständig ist:<br />
<br />
$ msp430-gdbproxy --port=2000 msp430<br />
<br />
Wenn das FET richtig an den Parallelport angeschlossen ist, sollte ungefähr der folgende Text angezeigt werden:<br />
<br />
info: msp430: Target device is a 'MSP430F12x' (type 11)<br />
notice: msp430-gdbproxy: waiting on TCP port 2000<br />
<br />
Hinweis: Falls /dev/parport0 nicht existiert, was sich so äußert:<br />
open: No such file or directory<br />
error: msp430: Could not initialize device interface (1)<br />
...als root ...<br />
mknod /dev/parport0 c 99 0 <br />
...eingeben.<br />
<br />
Hinweis: Bei udev im neuen Linuxkernel ab 2.6.x wird das Device /dev/parport0 nicht automatisch angelegt und man muss jedesmal neu den Aufruf mit mknod machen. Abhilfe schafft hier der Eintrag in der /etc/modules:<br />
ppdev<br />
<br />
Beim nächsten Booten dürfte der RAW-Parallelport vorhanden sein.<br />
<br />
=== Insight benutzen (Windows) ===<br />
<br />
Nachdem Insight gestartet ist (c:\msp430\bin\msp430-gdb.exe), klicke auf "File->Open" und wähle die elf-Datei (z.B. "test.elf") aus, die du debuggen möchtest.<br />
<br />
Klicke dann auf "Run->Connect to target" und stelle folgendes ein:<br />
<br />
Target: "Remote/TCP"<br />
Hostname: "localhost"<br />
Port: "2000"<br />
Set breakpoint at 'main': yes<br />
Set breakpoint at 'exit': yes<br />
Attach to target: yes<br />
Download Program: yes<br />
Command after attaching: "monitor erase all" (ACHTUNG: Optional, damit wird der gesamte Flash-Inhalt gelöscht!)<br />
Run Method: Continue from last Stop<br />
<br />
Wenn man auf "Ok" klickt, sollte Insight berichten, dass die Verbindung erfolgreich aufgenommen wurde, und gdbproxy sollte melden:<br />
<br />
"notice: msp430-gdbproxy: connected".<br />
<br />
Um den Debugging-Vorgang zu starten, klicke auf "Run" oder drücke einfach die Taste "r". Wenn alles geklappt hat, sollte nun der Sourcecode des Programmes angezeigt werden und die erste Zeile von main() grün markiert sein. Der rote Punkt ist der Breakpoint, der von Insight automatisch gesetzt wurde. Um selber Breakpoints zu setzen oder zu löschen, klicke auf den Strich '-' am Anfang der Zeile.<br />
<br />
Jetzt kann man mit 'c' (continue) das Programm am nächsten Breakpoint fortsetzen, die Zeilen mit 's' (step) der Reihe nach ausführen, oder einzelne Assemblerbefehle ausführen... aber Vorsicht mit "finish": Anscheinend hängt sich Insight manchmal bei diesem Befehl auf. Wenn man also eine Funktion beenden will, ist es wohl besser, einen Breakpoint auf das Ende der Funktion zu setzen und "continue" zu verwenden.<br />
<br />
=== DDD benutzen (Unix/Linux) ===<br />
<br />
Leider läuft Insight nicht besonders stabil und ist auch etwas umständlich zu bedienen. Wer Unix bzw. Linux verwendet, der ist deshalb mit DDD (http://www.gnu.org/software/ddd/) besser bedient. Um DDD zu verwenden braucht man msp430-gdbproxy und die Kommandozeilen-Version von GDB (msp430-gdb).<br />
<br />
Zuerst stellt man wie unter Windows über gdbproxy eine Verbindung zum JTAG-Adapter her. Wenn das funktioniert hat, kann man DDD starten. Als Parameter wird der zu verwendende Debugger (msp430-gdb) und die zu ladende ELF-Datei (test.elf) übergeben:<br />
<br />
$ ddd --debugger msp430-gdb test.elf<br />
<br />
Zunächst sollte man nun unter "Commands / Edit Buttons" ein paar Buttons anlegen, indem man die folgenden Zeilen in das Textfeld bei "Console Buttons" einfügt:<br />
<br />
target remote localhost:2000 // Connect<br />
monitor erase all // Erase<br />
load // Load<br />
monitor reset // Reset<br />
<br />
Um jetzt die Verbindung zum gdbproxy herzustellen muss man nur auf "Connect" klicken, danach auf "Erase" um den Flash-Speicher des Controllers zu löschen, und schließlich auf "Load", damit das Programm in den Controller geladen wird. Mit "Reset" kann man einen Reset auslösen (wer hätte das gedacht?).<br />
<br />
Wichtig: Nachdem einige breakpoints gesetzt sind, das Programm nicht mit "run" ausführen! Dass "run" Kommando wird benutzt um Programme auf dem lokalen Rechner zu starten. Für eingebettete Systeme ist das korrekte Kommando "continue" (siehe http://mspgcc.sourceforge.net/manual/x1602.html).<br />
<br />
=== GDB Scripts ===<br />
<br />
Hier eine kleine Ansammlung von Scripts, um download und reset via GDB etwas zu vereinfachen:<br />
<br />
[[Media:Gdb_scripts_win.zip]]</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=MSP430&diff=35157MSP4302009-03-17T21:32:11Z<p>Simulator: /* MSPGCC */</p>
<hr />
<div>== Einleitung ==<br />
<br />
Der MSP430 ist ein 16 Bit-Mikrocontroller von Texas Instruments (TI). Er wurde speziell für eine geringe Stromaufnahme entwickelt, so dass er besonders für batteriebetriebene Geräte geeignet ist. Es gibt verschiedene Typen mit 1-256 kB [[Flash-ROM]], 128-16384 Byte [[RAM]], teilweise mit Hardware-Multiplizierer, [[UART]], [[AD-Wandler]] oder LCD-Treiber, die meisten im [[SMD]]-Package mit 20 bis >100 Pins. Einige neuere aus der MSP430F2xxx-Serie gibt es auch im DIP-Package (Bezeichnung: MSPxxxx '''-N'''). Der MSP430F1121 zum Beispiel hat 4kB [[Flash-ROM]], 256B [[RAM]], 2 [[Timer]] und steckt in einem SO-20 Gehäuse. Seit dem Shrinking Ende 2008 gibt es einige Typen der Reihe MSP430X5xx mit integriertem USB-Controller (slave), RF-Transceiver, LDO-Spannungsregler und einer AES-Cryptoengine.<br />
<br />
== Entwicklungshardware ==<br />
Für den schnellen Einstieg stellt TI ein preisgünstiges Entwicklungssystem mit USB Schnittstelle zur Verfügung. ([http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool])<br />
<br />
Günstige Adapterplatinen und [[JTAG]]-Programmer für MSP430-Controller bekommt man bei [http://olimex.com/dev/ Olimex (Bulgarien)], in Deutschland bei http://shop.mikrocontroller.net und http://www.elektronikladen.de oder in Japan bei [http://passworld.co.jp/index.php?lang=GB&lieu=Soroban PassWorld].<br />
<br />
Einen einfachen Schaltplan für den [[JTAG]]-Programmer von TI bzw. Olimex gibt es [[Media:MSP430-JTAG-programmer.pdf|hier]]. Die Spannungsversorgung kommt im Gegensatz zum Original allerdings nicht vom Drucker-Port sondern muss extern (am besten vom MSP430 Board) bereitgestellt werden.<br />
<br />
Neben der JTAG-Programmierung bieten die MSP430-Controller auch die Möglichkeit, die Firmware über einen [[Bootloader]] einzuspielen. Die dafür erforderliche Hardware wird in der Application Note [http://focus.ti.com/docs/mcu/catalog/resources/appnoteabstract.jhtml?familyId=342&abstractName=slaa096d SLAA096d] von Texas Instruments beschrieben.<br />
<br />
=== Stromversorgung ===<br />
<br />
Der MSP430 benötigt eine Spannung zwischen 1,8 und 3,6 V. Einfach erzeugen kann man diese z.B. mit der folgenden Schaltung:<br />
<br />
http://www.mikrocontroller.net/images/lm317.png<br />
<br />
An den Eingang wird ein Steckernetzteil angeschlossen, die Ausgangsspannung lässt sich über das Potentiometer P1 einstellen.<br />
Benutzt man für P1 einen 500-Ohm-Typ, kann man die Spannung in einem Bereich von 1,2 Volt und knapp 3,6 Volt einstellen. Dann kann man den MSP430 nicht durch zu hohe Verorgungsspannungen zerstören.<br />
Einige neuere Typen der Reihe MSP430F5xx bieten einen integrierten Low-Drop-Spannungsregler an.<br />
<br />
== Dokumentation ==<br />
<br />
* TI's Website: http://www.msp430.com <br />
*:Für jede MSP430 Familie (z.B. MSP430F1xxx) gibt es ein generelles "datasheet" und einen detailierten "user guide". Die im user guide verwendeten Registerbezeichnungen (Ports, SFRs, etc.) findet man auch bei den meisten Compilern wieder.<br />
<br />
* Buch: Mikrocontrollertechnik Am Beispiel der MSP430-Familie<br />
*:Dieses Lehrbuch führt in die Grundlagen der Mikrorechentechnik ein. Es beschreibt sehr detailliert den Aufbau, die Funktion und die Handhabung von Mikrocontrollern am Beispiel des MSP430F1232. Programmbeispiele sind in Assembler und C enthalten. Ideal für Einsteiger mit geringen technischen Vorkenntnissen. Autor: Matthias Sturm ISBN:3-446-21800-9, Hanser Verlag<br />
<br />
== Software ==<br />
===Freie Tools===<br />
====MSP-CCE430====<br />
Dies ist die Entwicklungsumgebung von TI. Es gibt eine teure Pro-Version, aber eben auch eine Freeware-Version, die auf 16kB Codegrösse beschränkt ist. <br />
<br />
Dieser Entwicklungsumgebung liegt Eclipse zugrunde, wobei der C-Compiler und ein Debugger bereits eingebunden sind. Die Installation ist im Gegensatz zu MSPGCC kein Problem.<br />
<br />
* [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html Download MSP-CCE430]<br />
<br />
====MSPGCC====<br />
Man kann Programme für den MSP430 komplett mit freien Tools entwickeln. Mit dem C-Compiler [[MSPGCC]], dem Debugging-Programm [[GDB]]/Insight und einem beliebigen [[Texteditor]] kann man C-Programme schreiben, kompilieren, in den Controller programmieren und debuggen. In Kombination mit MSPGCC kann man auch die freie Entwicklungsumgebung Eclipse verwenden.<br />
<br />
Weblinks:<br />
* [http://www.mikrocontroller.net/articles/Eclipse_und_MSPGCC_unter_Windows Eclipse und MSPGCC unter Windows] (03/2009)<br />
* [http://matthias-hartmann.blogspot.com/ Use Eclipse and mspgcc - the easy way] (Windows 02/2009).<br />
* [http://www.mikrocontroller.net/Eclipse%20und%20MSPGCC/#Id220280 Eclipse und MSPGCC] (03/2006)<br />
* [http://inf.ntb.ch/infoportal/help/index.jsp?topic=/ch.ntb.infoportal/embeddedSystems_MSP430.html/ Eclipse + MSPGCC + Installationsanleitung Deutsch] (Windows 95, 98, Me, 2000, XP, Vista und Linux) <br />
*:(Die Installation und Konfiguration ist leider sehr schwierig und leider bisher in kaum einer Anleitung hinreichend gut erklärt.)<br />
<br />
* [http://kurt.on.ufanet.ru/ MSPFET - FREE MSP430 flash programming utility] (Windows 95, 98, Me, 2000, XP, Vista)<br />
<br />
=== Kommerzielle Compiler für MSP430 ===<br />
* [http://www.imagecraft.com/devtools_MSP430.html ICC430]<br />
*: 45-Tage Demo wird nach Ablauf auf 4 kByte Codegröße beschränkt<br />
* [http://www.htsoft.com/products/msp430ccompiler.php HI-TECH MSP430 C]<br />
*: 28-Tage Demo wird nach Ablauf unbrauchbar<br />
* [http://www.ide430.com/ IDE430]<br />
*: ''Dieser Link ist tot. Gibt es das Produkt noch?''<br />
* [http://www.rowley.co.uk/msp430/index.htm CrossWorks for MSP430]<br />
*: 30-Tage-Testversion nach Registrierung<br />
* [http://www.quadravox.com/AQ430.htm Quadravox AQ430]<br />
* [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html?DCMP=MSP430_ccessentials&HQS=Other+PR+ccessentials CCEssentials (Eclipse)]<br />
*: Frei und auf 8 kByte Codegröße beschränkt, seit V3 bis 16kByte Code frei<br />
* [http://www.iar.se/website1/1.0.1.0/675/1/index.php IAR Embedded Workbench for MSP430] <br />
*: 30-Tage-Testversion<br />
*: Freie auf 4 kByte Codegröße beschränkte "KickStart"-Edition.<br />
*: Kompatibel mit Windows7 7000 x64 (Stand: Februar 2009, Version 4.20.1)<br />
*: Nicht Windows Vista kompatibel (Stand: Mai 2008, Version 4.1A) < stimmt das noch?<br />
<br />
== Beispielanwendungen ==<br />
<br />
===Mathar.Com===<br />
Auf http://www.mathar.com gibt es ein paar Beispiele (in C), was man so alles mit dem MSP430 anstellen kann. Dort hat der Autor einige Anwendungen näher erläutert. Angefangen mit simplen Aufgaben wie LEDs leuchten lassen geht es weiter über eine LCD- und GLCD-Ansteuerung (HD44780- und KS0108-kompatibel) sowie einigen Beispielen zur Verwendung des integrierten A/D-Wandlers, des USARTs, des Timers und vielem mehr ... Als weitere Codebeispiele sind dort auch eine I2C-Softwareimplementation und eine CAN-Library für den MSP430 zu finden.<br />
<br />
===Examples Ordner der freien Toolchain MSPGCC===<br />
Der "examples"-Ordner bzw. "checkout" aus dem CVS vom [[MSPGCC]] ist auch sehr umfangreich: http://mspgcc.cvs.sourceforge.net/mspgcc/examples/<br />
<br />
===Codebeispiele auf Mikrokontroller.net===<br />
Einige [[MSP430 Codebeispiele]] finden sich auch hier in der Artikelsammlung.<br />
<br />
===uIP Port auf Mikrokontroller.net===<br />
Der Port des TCP/IP Stacks von Adam Dunkels [[MSP430_uIP_Port|uIP 1.0 für den MSP430 findet sich hier]].<br />
<br />
== Links ==<br />
<br />
* [http://www.mikrocontroller.net/forum/1/msp430 Beiträge zum MSP430 im Mikrocontroller.net Forum]<br />
* [http://mspgcc.sourceforge.net/manual/c68.html An introduction to the TI MSP430 low-power microcontrollers]<br />
* [http://tinymicros.com/embedded/MSP430/ The MSP430 Bugspray Database] - umfangreiche Datenbank für Bugs in MSP430-Controllern<br />
* [http://www.mathar.com www.mathar.com] - Tutorial für Einsteiger und Fortgeschrittene: LCD, ADC, USART, I2C, CAN Programmierung in C<br />
* [http://cnx.org/lenses/TexasInstruments/MSP430 Connexions - Texas Instruments MSP430] Tutorial (speziell für eZ430)<br />
* [http://msp430.info MSP430.info] - Portalseite für MSP430; Info, Projekte, Paper, Entwicklungstools...<br />
* [http://groups.yahoo.com/group/msp430 Yahoo group MSP430] - lebhaftes Forum mit vielen MSP430-Experten<br />
* [http://www.thomas-wedemeyer.de/elektronik/msp430/msp430.html Thomas Wedemeyer's MSP430-Seiten] - Kleine Beispiel Applikationen und Tips zur Nutzung von MSPGCC mit der Dev-C++ Entwicklungsumgebung<br />
[[Kategorie:Mikrocontroller]]<br />
* [http://homepage.hispeed.ch/py430/mspgcc/ msp430-gdb und Eclipse] - Eine Anleitung von Chris Liechti<br />
* [http://passworld.co.jp/index.php?lang=GB&lieu=GPS MSP430 GPS] - [http://passworld.co.jp/index.php?lang=GB&lieu=Oximeter MSP430 Puls-Oximeter]<br />
* [http://passworld.co.jp/ForumMSP430 MSP430 Forum]<br />
* [http://develissimo.net/de/msp430entwicklung.html MSPGCC + Eclipse + msp430-gdbproxy / Linux / Debian / Ubuntu] - Anleitung / Tutorial zur Installation der MSPGCC Toolchain + Eclipse + msp430-gdbproxy für Linux / Debian / Ubuntu Lang=Deutsch und Englisch<br />
* [http://www.sinelabore.com SinelaboreRT] - Generierung von Zustandsmaschinen in C speziell für kleine Low-Power Plattformen.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Eclipse_und_MSPGCC_unter_Windows&diff=35155Eclipse und MSPGCC unter Windows2009-03-17T20:28:59Z<p>Simulator: Die Seite wurde neu angelegt: Die Zusammenstellung eines freien Entwicklungs- und Debugging-Pakets für Mikrocontroller der MSP430 Reihe ist zum jetzigen Zeitpunkt, 03/2009, nicht ganz einfach. Es e...</p>
<hr />
<div>Die Zusammenstellung eines freien Entwicklungs- und Debugging-Pakets für Mikrocontroller der MSP430 Reihe ist zum jetzigen Zeitpunkt, 03/2009, nicht ganz einfach. Es existieren mehrere Möglichkeiten des Aufbaus der Werkzeugkette, perfekt ist aber keine. Unter diesem [http://matthias-hartmann.blogspot.com/ Link] findet man eine gute englischsprachige Beschreibung unter Verwendung von Eclipse, Zylin Embedded CDT, MSPGCC und MinGW.<br />
<br />
Im Unterschied dazu beruht die hier beschriebene Kombination auf Eclipse, einem Plugin zur Parametrierung ([http://homepage.hispeed.ch/py430/mspgcc/ net.sf.mspgcc.zip]) und [[MSPGCC]]. Zwischen PC und Zielsystem wird der [http://www.olimex.com/ Olimex] Parallelport-Adapter ‚MSP430-JTAG’ verwendet. Hinweise zur Nutzung des USB-Adapters ‚MSP430-JTAG-TINY’ findet man [http://www.cognimed.de/de/ueberuns/blauzahn/msp430_projekt.htm hier].<br />
<br />
= Download =<br />
Folgende Software-Komponenten sind für die Installation notwendig und über nachfolge Links verfügbar:<br />
<br />
* [http://downloads.sourceforge.net/mspgcc/mspgcc-20060502.exe?use_mirror=mesh ‚mspgcc-win32’ in der veralteten Version mspgcc-20060502.exe]<br />
* [http://mspgcc.sourceforge.net/ ‚mspgcc-win32’in der aktuellen Version mspgcc-????????.exe]<br />
* [http://www.eclipse.org/downloads/ Eclipse Package ‚Eclipse IDE for C/C++ Developers’ (Windows)]<br />
* [http://homepage.hispeed.ch/py430/mspgcc/net.sf.mspgcc.zip Plugin für Eclipse zur Parametrierung von MSPGCC (net.sf.mspgcc.zip)]<br />
* [http://www.mikrocontroller.net/wikifiles/8/8e/MSP430.Test.zip MSP430.Test.zip] mit gdb-target.ini, main.c und main.cpp<br />
<br />
= Installation =<br />
Die nachfolgenden Bilder zeigen als Laufwerk oftmals D:. Diese Bezeichnung muss entsprechend ihren lokalen Verhältnisse anpasst werden (C:).<br />
<br />
== Parallelport-Adapter ‚MSP430-JTAG’ ==<br />
Der Systemservice-Treiber GiveIO für diesen Adapter ist im MSPGCC Setup enthalten und wird dort automatisch mit installiert. Er bewerkstelligt die Hardware-Ansteuerung der PC-Parallelschnittstelle.<br />
<br />
== GNU C-Compiler für MSP430 ==<br />
Zuerst müssen wir die alte Version mspgcc-20060502.exe vollständig installieren. Bei der Installation sollte der Pfad auf C:\Programme\mspgcc geändert werden. Ist dieses erledigt kopieren wir die Datei C:\Programme\mspgcc\bin\msp430-gdbproxy.exe an einen sicheren Platz und deinstallieren nachfolgend das ganze MSPGCC Paket wieder.<br />
<br />
Als nächstes installieren wir in gleicher Weise die aktuelle Version des MSPGCC. Da die jetzt installierte neue Datei C:\Programme\mspgcc\bin\msp430-gdbproxy.exe kein richtig funktionierendes Debugging zulässt überschreiben wir sie mit der vorher gesicherten alten Version.<br />
<br />
== Eclipse IDE und Plugin ==<br />
Von den vorbereiteten ‚Eclipse Packages’ das Paket ‚Eclipse IDE for C/C++ Developers’ (Windows) downloaden. Den Inhalt der zip-Datei nach C:\Programme extrahieren. Es entsteht der neue Ordner C:\Programme\eclipse.<br />
<br />
Die Spezialisierung der IDE Eclipse auf MSPGCC erfolgt mittels Plugins. Den Inhalt der Datei net.sf.mspgcc.zip in den Ordner C:\Programme\eclipse extrahieren. Der Inhalt des ‚plugins’ Ordners der zip-Datei wird dabei nach C:\Programme\eclipse\plugins kopiert und vereinigt sich mit diesem.<br />
<br />
Jetzt sind alle notwendigen Programme installiert, aber vor dem ersten Start von Eclipse ist noch etwas Feinarbeit zu leisten. Zuerst legen wir in unserem Arbeitsbereich auf der Festplatte einen neuen Ordner zur Aufnahme der Eclipse Konfigurationsdaten und aller zukünftigen MSP430 Entwicklungsprojekte an. Zusätzlich einen Ordner für unser erstes Test-Projekt. Die Namen der zwei Ordner sind frei und nachfolgendes ist nur ein Beispiel:<br />
<br />
* …\Dateien von User\MSP430<br />
* …\Dateien von User\MSP430\Test<br />
<br />
Aus der Datei ‚MSP430.Test.zip’ kopieren wir gdb-target.ini nach …\MSP430 und main.c oder main.cpp nach …\MSP430\Test. Die Auswahl der main Datei richtet sich danach, ob wir in C oder C++ programmieren wollen.<br />
<br />
Nun können wir das Programm C:\Programme\eclipse\eclipse.exe erstmalig starten. Sollte eine Fehlermeldung das [http://java.sun.com/javase/downloads/ ‚Java SE Runtime Environment (JRE)’] verlangen, dann dieses zusätzlich downloaden und installieren. Eclipse möchte nach dem ersten Start sofort eine Ordner zum speichern der Konfiguration und zukünftiger Projekte anlegen. Ändern sie den vorgeschlagenen Pfad so, dass er auf unseren neuen Ordner ‚…\MSP430’ zeigt.<br />
<br />
= Konfiguration =<br />
Zur Konfiguration der Eclipse IDE gehören persönliche Einstellungen, der Debugger Proxy als Bindeglied zur Adapter-Hardware und der Debugger selbst.<br />
<br />
== Konfiguration General ==<br />
Als erste Konfiguration ist es vorteilhaft die IDE über ‚Window – Preferences’ an persönliche Vorlieben anzupassen. Unter ‚General – Keys’ ist das die Festlegung von Kurzwahltasten, unter ‚General – Workspace’ das automatische Kompilieren bzw. Speichern und unter ‚C/C++ - Code Style’ das Profil zur automatischen Formatierung des C-Quelltexts.<br />
<br />
[[Bild:MspEclipse01.png]]<br />
<br />
== Konfiguration Debugger Proxy ==<br />
Im nächsten Schritt parametrieren und starten wir über ‚Run – External Tools – External Tools Configuratations…’ den MSP430-GDBProxy. Gleichzeitig wird dadurch ein neuer Menüeintrag erzeugt worüber dieses Hintergrund-Programm späterhin, jeweils einmalig vor jeder Sitzung, gestartet wird.<br />
<br />
[[Bild:MspEclipse02.png]]<br />
<br />
* MSP430-GDBProxy<br />
* Argumente für Parallel Adapter: --port=3333 msp430<br />
* Argumente für USB Adapter: --port=3333 msp430 TIUSB<br />
* Argumente für USB (Spy-Bi-Wire): --port=3333 msp430 --spy-bi-wire TIUSB<br />
<br />
== Konfiguration Debugger ==<br />
Die IDE Eclipse ist so strukturiert, dass man für jedes Projekt die Konfiguration des Debuggers neu vornehmen muss. Um das zu vereinfachen legen wir ein Debugger-Template an von dem wir später, für jedes neue Projekt, ein Duplikat erzeugen. Das offene Feld ‚Project’ wird später im Duplikat ausgefüllt.<br />
<br />
[[Bild:MspEclipse03.png]]<br />
<br />
* Debug/Executable.elf<br />
* msp430-gdb<br />
* gdb-target.ini<br />
* 3333 <br />
<br />
= Erstes Projekt =<br />
Jetzt ist es an der Zeit das erste Test-Projekt zu konfigurieren. Der Projekttyp sollte dem Typ der main Datei entsprechen und der Projektname so lauten wie der Projektordner. Günstig ist es, entgegen dem hier gezeigten Vorgehen, die Konfigurationen Debug und Release gleichzeitig anzulegen. Dieses ist aber auch nachträglich möglich. Die detaillierten Einstellungen zum Kompilieren und Linken werden nach Betätigen von ‚Advanced settings…’ festgelegt.<br />
<br />
[[Bild:MspEclipse04.png]]<br />
<br />
Nachfolgende Einstellungen sind für C und C++ Projekte identisch. Ab dem nächsten Abschnitt folgen dann die Spezialitäten für C und C++.<br />
<br />
[[Bild:MspEclipse05.png]]<br />
<br />
* Der interne Builder ist schneller, erzeugt weniger Zwischendateien und die Consolen-Ausgabe ist kompakter.<br />
* C Projekt: msp430-gcc<br />
* C++ Projekt: msp430-g++<br />
<br />
[[Bild:MspEclipse06.png]] <br />
<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* msp430x???? <br />
<br />
[[Bild:MspEclipse07.png]]<br />
<br />
* Der Post-build Step dient zur Anzeige der Binärcode Größe.<br />
* msp430-size --format=sysv --radix=16 --target=elf32-msp430 Executable.elf <br />
* Die Artefact Bezeichnung ist gleich der Einstellung im Debugger Template.<br />
* Executable<br />
* elf<br />
<br />
== C Projekt ==<br />
<br />
[[Bild:MspEclipse08.png]]<br />
<br />
* Diese Flags sind nicht notwendig aber empfehlenswert: -fshort-enums -fsigned-char -mendup-at=main<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* msp430x???? <br />
<br />
[[Bild:MspEclipse09.png]]<br />
<br />
* Es schadet nichts dem Linker die Mathematik-Library mit den Gleitkomma-Funktionen bekannt zu machen. <br />
<br />
== C++ Projekt ==<br />
<br />
[[Bild:MspEclipse10.png]]<br />
<br />
* Diese Flags sind nicht notwendig aber empfehlenswert: -fshort-enums -fsigned-char -mendup-at=main -fno-rtti<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* msp430x???? <br />
* Weil der MSPGCC keine C++ Standardlibrary beinhaltet, der Linker diese aber laden will, müssen wir das unterbinden.<br />
<br />
[[Bild:MspEclipse11.png]]<br />
<br />
* Da die C++ Standardlibrary nicht existiert linken wir mit den C Librarys. ‚gcc’ muss als Letztes stehen.<br />
* Verwendeten Controllertyp eintragen. Bezeichnungen sind in mspgcc-manual.pdf, Abschnitt Compiler options, aufgeführt.<br />
* -mmcu=msp430x????<br />
<br />
== Kompilieren ==<br />
Auch wenn dem Test-Projekt noch keine Debugger-Konfiguration zugewiesen ist, können wir jetzt den ersten Build-Vorgang starten.<br />
<br />
[[Bild:MspEclipse12.png]]<br />
<br />
Nach Durchlauf ist das untere Eclipse-Fenster ‚Console’ interessant. Es zeigt eventuelle Fehlermeldungen von Compiler oder Linker. Ist kein Fehler aufgetreten, so hat der Linker die Datei …\Test\Debug\Executable.elf erzeugt.<br />
<br />
== Debugging ==<br />
Zunächst öffnen wir durch Doppelklick die Datei main.c oder main.cpp und wechseln zusätzlich in die andere Eclipse Ansicht ‚Debug Perspective’. Links oben im Fenster Debug sollte die Bestätigung des aktiven Debugger Proxy msp430-gdb sichtbar sein. Wenn nicht starten wir ihn über das Menü ‚Run – External Tools – MSP430-GDB-Proxy’.<br />
<br />
[[Bild:MspEclipse13.png]]<br />
<br />
Vor dem Debugging muss unserem Projekt nun einmalig die Debugger Konfiguration zugewiesen werden. Dazu duplizieren wir das bereits angelegte Debug Template, vergeben einen Namen für die Kopie und weisen der Kopie das Projekt Test zu.<br />
<br />
[[Bild:MspEclipse14.png]]<br />
<br />
Danach drücken wir ‚Debug’ und beobachten in den Fenstern Debug und Console wie Eclipse unser Anwenderprogramm auf das Zielsystem lädt und die Debugging Sitzung eröffnet. Der Programmlauf stoppt selbsttätig am Beginn der Funktion main() und wir sehen die erste Programmzeile vom main() markiert.<br />
<br />
Der eigentliche Debugging Vorgang entspricht nun dem Üblichen und interessant ist mehr was nicht funktioniert.<br />
<br />
Zunächst ist das der Befehl ‚Step over’. Er wird immer als ‚Step into’ ausgeführt. Um langwieriges Durchsteppen von Funktionsaufrufen zu vermeiden muss man deshalb den Befehl ‚Run to Line’ benutzen.<br />
<br />
Im Weiteren funktioniert der Befehl ‚Restart’ nicht. Es ist also notwendig mit ‚Terminate’ zu beenden und danach eine neue Debugging Sitzung zu beginnen.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse14.png&diff=35153Datei:MspEclipse14.png2009-03-17T19:54:40Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse13.png&diff=35152Datei:MspEclipse13.png2009-03-17T19:54:27Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse12.png&diff=35151Datei:MspEclipse12.png2009-03-17T19:54:12Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse11.png&diff=35150Datei:MspEclipse11.png2009-03-17T19:53:46Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse10.png&diff=35149Datei:MspEclipse10.png2009-03-17T19:49:28Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse09.png&diff=35148Datei:MspEclipse09.png2009-03-17T19:49:09Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse08.png&diff=35147Datei:MspEclipse08.png2009-03-17T19:48:48Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse07.png&diff=35146Datei:MspEclipse07.png2009-03-17T19:48:14Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse06.png&diff=35145Datei:MspEclipse06.png2009-03-17T19:47:49Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse05.png&diff=35144Datei:MspEclipse05.png2009-03-17T19:47:18Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse04.png&diff=35143Datei:MspEclipse04.png2009-03-17T19:46:58Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse03.png&diff=35142Datei:MspEclipse03.png2009-03-17T19:46:21Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse02.png&diff=35141Datei:MspEclipse02.png2009-03-17T19:45:50Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MspEclipse01.png&diff=35140Datei:MspEclipse01.png2009-03-17T19:45:13Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:MSP430.Test.zip&diff=35139Datei:MSP430.Test.zip2009-03-17T19:38:43Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34567Entscheidung Mikrocontroller2009-02-23T20:39:39Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
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.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/140$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]<br />
| ~ 15€<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]<br />
| ~ 65€<br />
|-<br />
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]<br />
| ~ 115€<br />
|-<br />
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]<br />
| ~ 30€<br />
|}<br />
<br />
[http://focus.ti.com/lit/ug/slau265/slau265.pdf 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.<br />
<br />
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.<br />
<br />
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 Codeschutz Sicherung des Mikrocontrollers auslösen.<br />
<br />
Die [http://www.olimex.com/dev/index.html Olimex] Produkte entsprechen in ihrer Funktion weitestgehend den TI Vorbildern und können mit jeder, die TI Werkzeuge unterstützenden, Software verwendet werden. Kleine Abweichungen bestehen bei der [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.<br />
<br />
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. <br />
<br />
Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34547Entscheidung Mikrocontroller2009-02-23T00:21:03Z<p>Simulator: /* [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/140$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]<br />
| ~ 15€<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]<br />
| ~ 65€<br />
|-<br />
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]<br />
| ~ 115€<br />
|-<br />
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]<br />
| ~ 30€<br />
|}<br />
<br />
[http://focus.ti.com/lit/ug/slau265/slau265.pdf 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.<br />
<br />
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.<br />
<br />
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 Codeschutz Sicherung des Mikrocontrollers auslösen.<br />
<br />
Die [http://www.olimex.com/dev/index.html Olimex] Produkte entsprechen in ihrer Funktion weitestgehend den TI Vorbildern und können mit jeder, die TI Werkzeuge unterstützenden, Software verwendet werden. Kleine Abweichungen bestehen bei der [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.<br />
<br />
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. <br />
<br />
Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34546Entscheidung Mikrocontroller2009-02-22T23:56:20Z<p>Simulator: /* [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/140$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]<br />
| ~ 15€<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]<br />
| ~ 65€<br />
|-<br />
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]<br />
| ~ 115€<br />
|-<br />
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]<br />
| ~ 30€<br />
|}<br />
<br />
[http://focus.ti.com/lit/ug/slau265/slau265.pdf 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.<br />
<br />
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.<br />
<br />
TI bezeichnet die Programmier- und Debugging-Hardware als Flash Emulation Tool (FET). Es existieren die Varianten ‚Parallel Port’ (Centronix Druckerschnittstelle) 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 Codeschutz Sicherung des Mikrocontrollers auslösen.<br />
<br />
Die [http://www.olimex.com/dev/index.html Olimex] Produkte entsprechen in ihrer Funktion weitestgehend den TI Vorbildern und können mit jeder, die TI Werkzeuge unterstützenden, Software verwendet werden. Kleine Abweichungen bestehen bei der [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.<br />
<br />
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. <br />
<br />
Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34545Entscheidung Mikrocontroller2009-02-22T23:51:15Z<p>Simulator: /* [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/140$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]<br />
| ~ 15€<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]<br />
| ~ 65€<br />
|-<br />
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]<br />
| ~ 115€<br />
|-<br />
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]<br />
| ~ 30€<br />
|}<br />
<br />
[http://focus.ti.com/lit/ug/slau265/slau265.pdf Programmierung] und Debugging der MSP430 erfolgt über JTAG-Schnittstelle und in neusten Varianten (MSP430F 20xx, 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.<br />
<br />
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.<br />
<br />
TI bezeichnet die Programmier- und Debugging-Hardware als Flash Emulation Tool (FET). Es existieren die Varianten ‚Parallel Port’ (Centronix Druckerschnittstelle) 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 Codeschutz Sicherung des Mikrocontrollers auslösen.<br />
<br />
Die [http://www.olimex.com/dev/index.html Olimex] Produkte entsprechen in ihrer Funktion weitestgehend den TI Vorbildern und können mit jeder, die TI Werkzeuge unterstützenden, Software verwendet werden. Kleine Abweichungen bestehen bei der [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.<br />
<br />
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. <br />
<br />
Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34542Entscheidung Mikrocontroller2009-02-22T22:00:02Z<p>Simulator: </p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/140$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId=95&tabId=140&familyId=342 TI MSP430] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p58_MSP430-JTAG-Parallelportkabel--MSP430-JTAG-.html MSP430 JTAG (parallel)]<br />
| ~ 15€<br />
|-<br />
| Olimex [http://shop.embedded-projects.net/product_info.php/info/p63_MSP430-USB-JTAG-Adapter--MSP430-JTAG-TINY-.html MSP430-JTAG-TINY (USB)]<br />
| ~ 65€<br />
|-<br />
| TI-FET [http://focus.ti.com/docs/toolsw/folders/print/msp-fet430uif.html MSP430 USB Debugging Interface]<br />
| ~ 115€<br />
|-<br />
| TI [http://focus.ti.com/docs/toolsw/folders/print/ez430-f2013.html MSP430 USB Stick Development Tool]<br />
| ~ 30€<br />
|}<br />
<br />
[http://focus.ti.com/lit/ug/slau265/slau265.pdf Programmierung] und Debugging der MSP430 erfolgt über JTAG-Schnittstelle und in neusten Varianten (MSP430F 20xx, 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.<br />
<br />
Jeder anwenderprogrammierbare MSP430 enthält einen [[Bootloader]]. Bei den Typenreihen MSP430F 1xx, F2xx und F4xx befindet er sich im ROM. Bei den MSP430F6xx im Flash-Speicher.<br />
<br />
TI bezeichnet die Programmier- und Debugging-Hardware als Flash Emulation Tool (FET). Es existieren die Varianten ‚Parallel Port’ (Centronix Druckerschnittstelle) 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 Codeschutz Sicherung des Mikrocontrollers auslösen.<br />
<br />
Die [http://www.olimex.com/dev/index.html Olimex] Produkte entsprechen in ihrer Funktion weitestgehend den TI Vorbildern und können mit jeder, die TI Werkzeuge unterstützenden, Software verwendet werden. Kleine Abweichungen bestehen bei der [http://www.olimex.com/dev/images/MSP430/SPY-BI-WIRE-CONNECTION.jpg Olimex Implementierung] der ‚Spy-Bi-Wire’ Verbindung des MSP430-JTAG-TINY.<br />
<br />
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. <br />
<br />
Als Entwicklungsumgebung stellt TI den auf der [http://www.eclipse.org/ Eclipse IDE] aufbauenden ‚Code Compose Essentials’ bereit. In der freien Version [http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html ‚CCE Core Edition’] ist dieses Paket auf 16kB Code begrenzt.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34536Entscheidung Mikrocontroller2009-02-21T14:15:03Z<p>Simulator: /* [http://www.atmel.com/ Atmel] */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/140$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
[http://www.mikrocontroller.net/topic/107070 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.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Diskussion:Entscheidung_Mikrocontroller&diff=34535Diskussion:Entscheidung Mikrocontroller2009-02-21T12:47:21Z<p>Simulator: </p>
<hr />
<div>Beim Stromverbrauch wäre natürlich auch ein Vergleich mit den MSP430 nett, aber leider hat TI nicht diese schönen Diagramme wie ATMEL in den Datenblättern und gerade bei 32 bzw. 100kHz kann man das auch nicht aus den angegebenen Formeln ausrechnen. Markus<br />
<br />
Ich könnte schon mal messen, aber bei welcher Belastung wurden denn die Atmega8 Werte aufgenommen? Ausserdem benutze ich aus Faulheit bisher nur den internen Oszilator... (ozel)<br />
<br />
Die Atmel-Werte sind sind wohl im ganz normalen active-Mode, ohne Belastung der I/O-Pins und wahrscheinlich mit einer Endlosschleife oder so gemessen worden. Da in den Atmel-Datenblättern ganze (gemessene) Graphen drin sind, gehe ich mal davon aus, daß sie den Takt mit einem Funktionsgenerator erzeugt haben.<br />
<br />
Beim Überfliegen der MSP430-Datenbläter ist mir auch nicht klargeworden, was der 2. Takt mit dem Stromverbrauch zu tun hat. - Markus<br />
<br />
@Mah<br />
Dein Beitrag:<br />
<br />
Bei AVR JTAG ICE MKII - CN clones sollte man genau auf die<br />
unterstütze Software-Umgebung achten - "AVR Studio supported"<br />
kann durchaus heissen: "avrdude is not supported".<br />
<br />
hat vielleicht Berechtigung, ist im Abschnitt Debugging aber deplaziert.<br />
Vermutungen helfen außerdem nicht weiter.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34534Entscheidung Mikrocontroller2009-02-21T12:45:09Z<p>Simulator: Änderung 34531 von Mah (Diskussion) wurde rückgängig gemacht.</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/160$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34525Entscheidung Mikrocontroller2009-02-20T21:35:57Z<p>Simulator: </p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Unterstützung/Community ==<br />
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.<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/160$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Programmübertragung ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Mikrocontroller mit integriertem [[Bootloader]] können mit der entsprechenden PC-Software direkt über den seriellen Port programmiert werden.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34510Entscheidung Mikrocontroller2009-02-19T21:00:34Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
=== [http://www.atmel.com/ Atmel] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]<br />
| ~ 85$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone<br />
| ~ 280€/160$<br />
|-<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
=== [http://www.microchip.com/ Microchip] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/40€<br />
|-<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|}<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
=== [http://www.zilog.com/ Zilog] ===<br />
<br />
{| border="1"<br />
|-<br />
!System<br />
!Preis<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
Die [[Zilog]] Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34506Entscheidung Mikrocontroller2009-02-19T13:49:02Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://atmel.com/ Atmel]<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII]<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|-<br />
| [http://www.microchip.com/ Microchip]<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / [http://www.sivava.com/MPLAB_ICD2.html Clone]<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|-<br />
| [[Zilog]]<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
Die Zilog Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34500Entscheidung Mikrocontroller2009-02-19T10:15:47Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://atmel.com/ Atmel]<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII]<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|-<br />
| [http://www.microchip.com/ Microchip]<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|-<br />
| [[Zilog]]<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer. Zu beachten ist, dass einige kleine PICs keine In-Circuit Debugging Hardware besitzt. Sie sind nur mit Hilfe eines kostspieligen [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538769 Header Boards] debugbar.<br />
<br />
Die Zilog Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34499Entscheidung Mikrocontroller2009-02-19T09:50:07Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://atmel.com/ Atmel]<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII]<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|-<br />
| [http://www.microchip.com/ Microchip]<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|-<br />
| [[Zilog]]<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips freier [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateure verschmerzbarer.<br />
<br />
Die Zilog Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34489Entscheidung Mikrocontroller2009-02-18T21:12:18Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://atmel.com/ Atmel]<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII]<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|-<br />
| [http://www.microchip.com/ Microchip]<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|-<br />
| [[Zilog]]<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
Alle Typen von Microchip Debugger Hardware werden von Microchips [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] unterstützt. Diese etwas angestaubte und verwirrende 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, keine Codeoptimierung. Microchips C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und/oder [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] können zusätzlich installiert werden. In der zum freien Download bereitstehenden ‚Student Edition’ stellen sie nach 60 Tagen die Codeoptimierung ein. Das MPLAB Setup bietet optional die Installation der, im nächsten Absatz behandelten, HI-TECH IDE ‚HI-TIDE 3’ an.<br />
<br />
Die Debugger Hardware ICD 2 von Microchip wird auch von der freien, auf [http://www.eclipse.org/ Eclipse] basierenden, HI-TECH IDE [http://www.htsoft.com/downloads/demos.php#hitide ‚HI-TIDE 3’] unterstützt. Diese moderne aber trotzdem konfuse IDE kann zusammen mit Microchips MPLAB oder separat installiert werden. Zusätzlich zu installieren sind HI-TECHs C-Compiler für die Microchip Reihen [http://www.htsoft.com/microchip/products/compilers/piccpro-modes.php PIC10/12/16], [http://www.htsoft.com/microchip/products/compilers/picc18pro-modes.php PIC18] und/oder [http://www.htsoft.com/microchip/products/compilers/pic32-modes.php PIC32]. Ihre im ‚Lite mode’ bestehende Einschränkung wurde bereits erwähnt.<br />
<br />
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 fehlende Codeoptimierung ist für Amateur verschmerzbarer.<br />
<br />
Die Zilog Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34452Entscheidung Mikrocontroller2009-02-17T09:16:40Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Dokumentation ==<br />
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.<br />
<br />
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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://atmel.com/ Atmel]<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII]<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|-<br />
| [http://www.microchip.com/ Microchip]<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046&part=DV164005 MPLAB ICD 2] / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]<br />
| ~ 190€<br />
|-<br />
| [[Zilog]]<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
Der Microchip’s [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002 MPLAB IDE] beiliegende freie HI-TECH C-Compiler (Lite mode) für PIC10/12/16, PIC18 und PIC32 hat keine Codeoptimierung. Der gleichfalls beigegebene CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die zum freien Download bereitstehenden Student Editionen der Microchip C-Compiler für [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014 PIC18], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535364 PIC24], [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535363 dsPIC DSCs] und [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en532454 PIC32] stellen nach 60 Tagen die Codeoptimierung ein.<br />
<br />
Die Zilog Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34441Entscheidung Mikrocontroller2009-02-16T20:26:56Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://atmel.com/ Atmel]<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII]<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|-<br />
| [http://www.microchip.com/ Microchip]<br />
| MPLAB PICkit2 / PICkit2 Debug Express<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit3 Debug Express<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 2 / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ~ 190€<br />
|-<br />
| [[Zilog]]<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei dem C++ Compiler der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
Der Microchip’s MPLAB IDE beiliegende freie HI-TECH C-Compiler (Lite mode) für PIC10/12/16, PIC18 und PIC32 hat keine Codeoptimierung. Der gleichfalls beigegebene CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die zum freien Download bereitstehenden Student Editionen der Microchip C-Compiler für PIC18, PIC24, dsPIC DSCs und PIC32 stellen nach 60 Tagen die Codeoptimierung ein.<br />
<br />
Die Zilog Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34440Entscheidung Mikrocontroller2009-02-16T20:24:01Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| [http://atmel.com/ Atmel]<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII]<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]<br />
| ~ 550€<br />
|-<br />
| [http://www.microchip.com/ Microchip]<br />
| MPLAB PICkit2 / PICkit2 Debug Express<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit3 Debug Express<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 2 / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ~ 190€<br />
|-<br />
| [[Zilog]]<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]<br />
| ~ 70$<br />
|}<br />
<br />
[http://atmel.com/products/avr32/default.asp AVR32 Controller (32-Bit)] können mit Atmels freiem [http://atmel.com/dyn/products/tools_card.asp?tool_id=4116 AVR32 Studio], basierend auf der [http://www.eclipse.org/ Eclipse IDE], programmiert und debugt werden. Die IDE bedient sich dabei dem C++ Compiler aus der der [http://atmel.com/dyn/products/tools_card.asp?tool_id=4118 AVR32 GNU Toolchain].<br />
<br />
Der Debugger für [http://atmel.com/products/avr/default.asp AVR 8-Bit] RISC Controller ist in Atmels freie [http://atmel.com/dyn/products/tools_card.asp?tool_id=2725 AVR Studio] IDE integriert. In Verbindung mit dem GNU C++ Compiler für AVR ([http://winavr.sourceforge.net/ WinAVR]) und der integrierten Bibliothek [http://www.nongnu.org/avr-libc/ AVR Libc] ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
Der [[JTAG|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.<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.<br />
<br />
Der Microchip’s MPLAB IDE beiliegende freie HI-TECH C-Compiler (Lite mode) für PIC10/12/16, PIC18 und PIC32 hat keine Codeoptimierung. Der gleichfalls beigegebene CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die zum freien Download bereitstehenden Student Editionen der Microchip C-Compiler für PIC18, PIC24, dsPIC DSCs und PIC32 stellen nach 60 Tagen die Codeoptimierung ein.<br />
<br />
Die Zilog Entwicklungssysteme [http://www.zilog.com/index.php?option=com_content&task=view&id=40&Itemid=137 ZDS II] (C/ASM) für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Z8 Encore!®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Z8 Encore! XP®], [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Z8 Encore! MC™] sowie [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 ZNEO™ Z16F] Controller haben keine Beschränkungen sind aber ganz zu Unrecht in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34427Entscheidung Mikrocontroller2009-02-16T14:46:01Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| JTAG ICE (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| Atmel<br />
| AVR Dragon (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| JTAG ICE MKII<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| AVR ONE!<br />
| ~ 550€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit2 / PICkit2 Debug Express<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit3 Debug Express<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 2 / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ~ 190€<br />
|-<br />
| Zilog<br />
| USB Smart Kabel<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| Ethernet Smart Kabel<br />
| ~ 70$<br />
|}<br />
<br />
AVR32 Controller (32-Bit) können mit Atmels freiem AVR32 Studio programmiert und debugt werden. Die IDE bedient sich dabei dem C++ Compiler aus der der AVR32 GNU Toolchain.<br />
<br />
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) ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
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<br />
<br />
Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Programmcode debuggen.<br />
<br />
Der Microchip’s MPLAB IDE beiliegende freie HI-TECH C-Compiler (Lite mode) für PIC10/12/16, PIC18 und PIC32 hat keine Codeoptimierung. Der gleichfalls beigegebene CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die zum freien Download bereitstehenden Student Editionen der Microchip C-Compiler für PIC18, PIC24, dsPIC DSCs und PIC32 stellen nach 60 Tagen die Codeoptimierung ein.<br />
<br />
Die [[Zilog]] Entwicklungssysteme (C/ASM) für 8- und 16-Bit Controller haben keine Beschränkungen sind aber, ganz zu Unrecht, in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34424Entscheidung Mikrocontroller2009-02-16T10:34:20Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| JTAG ICE (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| Atmel<br />
| AVR Dragon (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| JTAG ICE MKII<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| AVR ONE!<br />
| ~ 550€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit2 / PICkit2 Debug Express<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit3 Debug Express<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 2 / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ~ 190€<br />
|-<br />
| Zilog<br />
| USB Smart Kabel<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| Ethernet Smart Kabel<br />
| ~ 70$<br />
|}<br />
<br />
Der Debugger für Atmel Controller ist in Atmels freie AVR Studio IDE integriert. In Verbindung mit dem GNU C-Compiler für AVR (WinAVR) ist Hochsprach-Entwicklung und -Debugging möglich.<br />
<br />
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<br />
<br />
Atmel [[AVR]] Dragon kann alle ATtiny, ATmega programmieren ist aber auf 32 kB debugbaren Programmcode begrenzt.<br />
<br />
Der Microchip’s MPLAB IDE beiliegende freie HI-TECH C-Compiler (Lite mode) für PIC10/12/16, PIC18 und PIC32 hat keine Codeoptimierung. Der gleichfalls beigegebene CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die zum freien Download bereitstehenden Student Editionen der Microchip C-Compiler für PIC18, PIC24, dsPIC DSCs und PIC32 stellen nach 60 Tagen die Codeoptimierung ein.<br />
<br />
[[Zilog]] Produkte haben keine Beschränkungen sind aber, ganz zu Unrecht, in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34418Entscheidung Mikrocontroller2009-02-16T09:55:46Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| JTAG ICE (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| Atmel<br />
| AVR Dragon (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| JTAG ICE MKII<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| AVR ONE!<br />
| ~ 550€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit2 / PICkit2 Debug Express<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit3 Debug Express<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 2 / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ~ 190€<br />
|-<br />
| Zilog<br />
| USB Smart Kabel<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| Ethernet Smart Kabel<br />
| ~ 70$<br />
|}<br />
<br />
Der 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<br />
<br />
Atmel [[AVR]] Dragon kann alle ATtiny, ATmega programmieren ist aber auf 32 kB debugbaren Programmcode begrenzt.<br />
<br />
Der Microchip’s MPLAB IDE beiliegende freie HI-TECH C-Compiler (Lite mode) für PIC10/12/16, PIC18 und PIC32 hat keine Codeoptimierung. Der gleichfalls beigegebene CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt. Die zum freien Download bereitstehenden Student Editionen der Microchip C-Compiler für PIC18, PIC24, dsPIC DSCs und PIC32 stellen nach 60 Tagen die Codeoptimierung ein.<br />
<br />
[[Zilog]] Produkte haben keine Beschränkungen sind aber, ganz zu Unrecht, in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34413Entscheidung Mikrocontroller2009-02-15T22:42:40Z<p>Simulator: </p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| JTAG ICE (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| Atmel<br />
| AVR Dragon (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| JTAG ICE MKII<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| AVR ONE!<br />
| ~ 550€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit2 / PICkit2 Debug Express<br />
| ~ 30€/55€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit3 Debug Express<br />
| ~ 65€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 2 / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ~ 190€<br />
|-<br />
| Zilog<br />
| USB Smart Kabel<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| Ethernet Smart Kabel<br />
| ~ 70$<br />
|}<br />
<br />
Der JTAG ICE Clone kann nur ältere ATmega Controller debuggen:<br />
<br />
* ATmega16, ATmega16L<br />
* ATmega162, ATmega162L, ATmega162V<br />
* ATmega165, ATmega165V<br />
* ATmega169, ATmega169L, ATmega169V<br />
* ATmega32, ATmega32L<br />
* ATmega323, ATmega323L<br />
* ATmega64, ATmega64L<br />
* ATmega128, ATmega128L, AT90CAN128<br />
<br />
Atmel [[AVR]] Dragon kann alle ATtiny, ATmega programmieren ist aber auf 32 kB debugbaren Programmcode begrenzt.<br />
<br />
Der Microchip’s MPLAB IDE beiliegende freie HI-TECH C-Compiler (Lite mode) für PIC10/12/16, PIC18 und PIC32 hat keine Codeoptimierung. Der gleichfalls beigegebene CCS Compiler für PIC18F45k20 ist auf 2kWord Programmcode begrenzt.<br />
<br />
[[Zilog]] Produkte haben keine Beschränkungen sind aber, ganz zu Unrecht, in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34371Entscheidung Mikrocontroller2009-02-12T20:13:23Z<p>Simulator: /* Debugging */</p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
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. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testcode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellcode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| JTAG ICE (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| Atmel<br />
| AVR Dragon (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| JTAG ICE MKII<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| AVR ONE!<br />
| ~ 550€<br />
|-<br />
| Microchip<br />
| MPLAB PICkit2<br />
| ~ 60€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 2 / Clone<br />
| ~ 90€/~40€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ~ 190€<br />
|-<br />
| Zilog<br />
| USB Smart Kabel<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| Ethernet Smart Kabel<br />
| ~ 70$<br />
|}<br />
<br />
Der JTAG ICE Clone kann nur ältere ATmega Controller debuggen:<br />
<br />
* ATmega16, ATmega16L<br />
* ATmega162, ATmega162L, ATmega162V<br />
* ATmega165, ATmega165V<br />
* ATmega169, ATmega169L, ATmega169V<br />
* ATmega32, ATmega32L<br />
* ATmega323, ATmega323L<br />
* ATmega64, ATmega64L<br />
* ATmega128, ATmega128L, AT90CAN128<br />
<br />
Atmel [[AVR]] Dragon kann alle ATtiny, ATmega programmieren ist aber auf 32 kB debugbaren Programmcode begrenzt.<br />
<br />
[[Zilog]] Produkte sind, ganz zu Unrecht, in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Entscheidung_Mikrocontroller&diff=34364Entscheidung Mikrocontroller2009-02-12T14:07:14Z<p>Simulator: </p>
<hr />
<div>[[Category:Mikrocontroller]]<br />
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: [[AVR_PIC_51-Vergleich]]<br />
<br />
== Verfügbarkeit ==<br />
* 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.<br />
* 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.<br />
* 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:<br />
** AVR AT90-Reihe, <br />
** AVR ATMega 103(L), 161(L), 163(L), 323(L).<br />
* 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.<br />
* Dagegen sind Mikrocontroller der [[8051|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.<br />
<br />
== Preis ==<br />
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.<br />
<br />
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).<br />
<br />
== Bauformen == <br />
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 [[Breadboard]]s 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.<br />
<br />
Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:<br />
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)<br />
* AVR ATMega 64, 128, 169<br />
<br />
In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:<br />
* AVR ATMega 8, 16, 32<br />
* viele 8051-Derivate, z.B. Atmel 89S8252<br />
<br />
== Spannung ==<br />
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:<br />
* 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.<br />
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).<br />
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].<br />
<br />
* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Spannungsregler]] (z.B. 78xx) ist also Pflicht!<br />
* 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).<br />
<br />
== Stromverbrauch ==<br />
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 optimiert.<br />
<br />
Der Stromverbrauch hängt auch stark vom Takt und der Versorgungsspannung ab. <br />
<br />
<br />
{| border=1 cellspacing=0<br />
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)<br />
|-<br />
! 32KHz <br />
|62µA||80µA||45µA||-<br />
|-<br />
! 100KHz <br />
|0,3mA||0,5mA||-||-<br />
|-<br />
!1MHz, 2MHz*<br />
|1,5mA ||2,3mA||4mA||-<br />
|-<br />
!8MHz, 4MHz*<br />
|5mA ||7/15mA**||-||4.5mA<br />
|-<br />
!16MHz, 20MHz*<br />
| - ||20mA||-||20mA<br />
|}<br />
<br />
[*] 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.<br />
<br />
[**] Angaben sind in der Folge Idle/Active (Quelle: Atmel, ATmega8/L, doc2486.pdf).<br />
<br />
== Takt/Geschwindigkeit ==<br />
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.<br />
<br />
Bei einem Geschwindigkeitsvergleich sollte man beachten, dass man nicht einfach den Takt vergleichen kann: <br />
* 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]]).<br />
* 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. <br />
* 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.<br />
<br />
== Speicher ==<br />
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 [[RAM#SRAM|SRAM]]. Fehlt letzteres, dann kann es mit der Compilerunterstützung schwierig werden.<br />
<br />
Zu unterscheiden sind hier außerdem Controller in [[Von Neumann-Architektur|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.<br />
<br />
== Onboard-Peripherie ==<br />
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.<br />
<br />
== Programmiersprachen ==<br />
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.)<br />
<br />
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.<br />
<br />
Für einige Controllerfamilien (z.B. AVR, ARM, MSP430) gibt es eine Portierung des kostenlosen [[GCC|GNU-C-Compilers]], wodurch C auch im Hobby-Bereich stark vertreten ist und es auch viele Programmierbeispiele dafür gibt.<br />
<br />
== Programmübertragung ==<br />
Irgendwie muss das Programm zum Mikrocontroller kommen. Früher war dazu in den meisten Fällen ein teures und umständlich zu handhabendes Programmiergerät notwendig, heute sind die meisten Mikrocontroller über eine spezielle ISP-Schnittstelle oder über das [[UART]] "In-System"-programmierbar. Controller mit integriertem [[Bootloader]] kann man mit der entsprechenden Software direkt über den seriellen Port eines PCs programmieren. Für Controller mit ISP- oder [[JTAG]]-Schnittstelle ([[AVR]], [[MSP430]]) benötigt man einen speziellen Programmieradapter, den man (meistens in verschiedenen Ausführungen) kaufen oder selber bauen kann.<br />
<br />
== Debugging ==<br />
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.<br />
<br />
Die preisgünstigste aber auch unkomfortabelste Art des Debuggings ist der Einbau von Testkode in das Programm. Dieser Testkode 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 Testkode erdacht und in das Programm eingefügt werden. Danach wird das Programm kompiliert/assembliert und in den Flashspeicher des Mikrocontrollers gebrannt. Zu guter Letzt muss das Programm von Begin an durchlaufen und mit etwas Glück liefert der Testkode Informationen über das Problem.<br />
<br />
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:<br />
<br />
* Programm- und Datenspeicher des Mikrocontrollers.<br />
* Arbeits- und Konfigurationsregister des Mikrocontrollers.<br />
* Programm Quellkode in Hochsprache (z.B. C) und/oder Assembler.<br />
* Werte von Programm Variablen.<br />
<br />
Ausgehend vom Quellkode/Assembler-Fenster kann man den Programmlauf an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.<br />
<br />
Der Programmlauf kann in einem Software-Simulator oder direkt auf dem Mikrocontroller erfolgen. Leider können Simulatoren weder die Signale der Controller Umgebung noch Interrupts realistisch nachahmen. Hier hilft nur In-System Debugging direkt auf dem Zielsystem.<br />
<br />
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 Debugger Software 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.<br />
<br />
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:<br />
<br />
{| border="1"<br />
|-<br />
!Hersteller<br />
!System<br />
!Preis<br />
|-<br />
| Clone<br />
| JTAG ICE (wenige ATmega Typen)<br />
| ~ 35€<br />
|-<br />
| Atmel<br />
| AVR Dragon (Debugging <= 32kB)<br />
| ~ 55€<br />
|-<br />
| Atmel<br />
| JTAG ICE MKII<br />
| ~ 280€<br />
|-<br />
| Atmel<br />
| AVR ONE!<br />
| ~ 550€<br />
|-<br />
| Microchip<br />
| MPLAB ICD 3<br />
| ab 190€<br />
|-<br />
| Zilog<br />
| USB Smart Kabel<br />
| ~ 30$<br />
|-<br />
| Zilog<br />
| Ethernet Smart Kabel<br />
| ~ 70$<br />
|}<br />
<br />
Der JTAG ICE Clone kann nur ältere ATmega Controller debuggen:<br />
<br />
* ATmega16, ATmega16L<br />
* ATmega162, ATmega162L, ATmega162V<br />
* ATmega165, ATmega165V<br />
* ATmega169, ATmega169L, ATmega169V<br />
* ATmega32, ATmega32L<br />
* ATmega323, ATmega323L<br />
* ATmega64, ATmega64L<br />
* ATmega128, ATmega128L, AT90CAN128<br />
<br />
Atmel [[AVR]] Dragon kann alle ATtiny, ATmega programmieren ist aber auf 32 kB debugbaren Programmkode begrenzt.<br />
<br />
[[Zilog]] Produkte sind, ganz zu Unrecht, in Europa kaum bekannt oder erhältlich.<br />
<br />
== Störfestigkeit ==<br />
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. <br />
<br />
== Unterstützung/Community ==<br />
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.</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Zilog_ZNEO_Bootloader&diff=34022Zilog ZNEO Bootloader2009-01-27T23:47:37Z<p>Simulator: /* Einleitung */</p>
<hr />
<div>== Einleitung ==<br />
Resident in den obersten 4kByte des EROM-Flash Speichers dient dieser Kode zum Laden jeweils eines Anwenderprogramms via USB/RS232 vom PC in den Mikrokontroller Flash oder RAM. Um seine Aufgabe zu erfüllen wird er einmalig in den Mikrokontroller gebrannt.<br />
<br />
Das zu ladende Anwenderprogramm muss im Intel Hex32 Format vorliegen, so wie es vom Zilog Entwicklungspaket ZDS II erzeugt wird.<br />
<br />
Der Bootloader kann sich selbst downloaden und aktualisieren. Dabei wird ein eventuell vorhandenes Anwenderprogramm gelöscht.<br />
<br />
Auf Seiten des PC wird ein beliebiges Terminal Programm, z.B. HyperTerminal, benötigt. Die Kommunikation erfolgt mit maximal 115kBaud.<br />
<br />
Bei der Entwicklung wurde den besonderen Erfordernissen einer über USB getunnelten RS232 Verbindung mit vom Zielsystem gespeisten FTDI Chip FT232R Rechnung getragen.<br />
<br />
== Funktionsweise ==<br />
Nach Reset des Mikrokontrollers wird als Erstes der Kode des Bootloaders ausgeführt. Dieser verzweigt in die beiden nachfolgenden Möglichkeiten:<br />
<br />
* Im Normalfall startet der Bootloader sofort das im Mikrokontroller vorhandene Anwenderprogramm und beendet sich dabei selbst bis zum nächsten Reset.<br />
* Soll das Anwenderprogramm geändert werden geht der Bootloader in Kommunikation mit dem PC und stellt dort ein Auswahlmenü dar.<br />
<br />
Üblicherweise erfolgt die Verzweigung zur PC-Kommunikation wenn nach Reset sofort eine Zeichenfolge via RS232 vom PC empfangen wird. Bei der über USB getunnelte RS232 Verbindung ist dieses Verfahren aber nicht anwendbar wenn der verwendete FTDI Chip FT232R seine Betriebsspannung vom Zielsystem erhält.<br />
Da der FT232R vor Einschalten des Zielsystems ohne Funktion ist kann der PC keinen virtuellen COM-Port anlegen und das Terminalprogramm keine Verbindung aufbauen. Nach Einschalten des Zielsystems wird der Bootloader deshalb niemals die wichtige Zeichenfolge zur Funktionsverzweigung vom PC erhalten.<br />
<br />
Für diesen Bootloader wurde deshalb ein anderes Erkennungsverfahren gewählt. Es basiert auf der Auswertung des statischen Pegels am TxD-Ausgang des FT232R und funktioniert sowohl bei Speisung des FTDI Chips vom Zielsystem als auch bei Speisung über USB vom PC. Beide Varianten sind auf dem nachfolgenden Bild unter Verwendung einer Mini-B USB Buchse dargestellt.<br />
<br />
http://www.mikrocontroller.net/wikifiles/1/12/ZneoFT232RL.png<br />
<br />
Ist keine elektrische USB-Verbindung zum PC etabliert so ist der TxD-Ausgang des FT232R hochohmig. Ein 150kOhm Widerstand nach Masse zieht den Pegel an TxD auf Low. Der Bootloader bewertet diesen Pegel als fehlende USB-Verbindung und startet das Anwenderprogramm.<br />
Verbindet ein USB-Kabel den aktiven FTDI Chip mit dem PC so liegt am TxD-Ausgang High Pegel. Der nach Reset startende Bootloader interpretiert das als Aufforderung zur Kommunikation, initialisiert den ZNEO UART und wartet auf das erste vom PC gesendete Zeichen. Nach Dessen Erhalt sendet er das Auswahlmenü zum Terminalprogramm<br />
<br />
Wie in nachfolgendem Bild gezeigt, besteht das Menü nur aus zwei Punkten. Wird D zum Download gewählt muss nachfolgend die *.hex Datei vom PC-Programm gesendet werden.<br />
Ist ein Anwenderprogramm auf dem ZNEO gespeichert so wird auch der Menüpunkt G angezeigt.<br />
<br />
http://www.mikrocontroller.net/wikifiles/1/18/ZneoHyperTerminal.png<br />
<br />
Die richtige Reihenfolge der Bedienschritte zum Download und Start eines neuen Anwenderprogramms ist folgende:<br />
* Zielsystem und PC mittels USB-Kabel verbinden.<br />
* Einschalten des Zielsystems.<br />
* Wenn notwendig, Treiber für FT232R-Chip installieren.<br />
* Start eines Terminalprogramms und verbinden mit dem virtuellen COMx-Port bei folgenden Parametern:<br />
** 115200 Bits pro Sekunde:<br />
** 8 Datenbits<br />
** keine Parität<br />
** 1 Stoppbit<br />
** keine Flusssteuerung<br />
* Betätigen einer Zeichentaste auf dem PC damit der Bootloader das Auswahlmenü sendet.<br />
* Betätigen der Taste D für Download.<br />
* Auswahl und senden der HEX-Datei über das Terminalprogramm im Textformat.<br />
* Nach Abschluss des Downloads, drücken der Taste G zum Start des neuen Anwenderprogramms.<br />
<br />
Wird eine neue Version des Bootloaders zum Zielsystem gesendet so startet der aktualisierte Programm Kode nach Abschluss des Downloads selbständig.<br />
== Kompilierung ==<br />
Die hier unter Download verfügbare ZIP-Datei enthält das ZDS II Projekt des Bootloaders, geschrieben in C und konfiguriert für den Z16F2810VH.<br />
Bei Umstellung auf einen anderen Z16 Mikrokontroller sind in den Project Settings für Debug und Release jeweils anzupassen:<br />
<br />
* General - CPU<br />
* Debugger – Setup – Clock Frequency (MHz) - Internal – 5.52960<br />
<br />
In der Datei application.h befinden sich zusätzliche Optionen bezüglich UART und Menütext.<br />
== Download ==<br />
* [http://www.mikrocontroller.net/wikifiles/a/af/ZneoBootLoader.zip ZneoBootLoader.zip - Version 1.00]<br />
== Links ==<br />
* [http://www.mikrocontroller.net/articles/ZNEO ZNEO]<br />
* [http://www.zilog.com/ Zilog Incorporation]<br />
* [http://www.mikrocontroller.net/articles/Bootloader Bootloader]<br />
[[Category:Projekte]]</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=ZNEO&diff=34021ZNEO2009-01-27T22:53:54Z<p>Simulator: /* Entwicklungssoftware */</p>
<hr />
<div>== Einleitung ==<br />
Der Zilog ZNEO (Z16Fx) ist ein 16/32-Bit Mikrocontroller. Der interne Flash Speicher ist 16-Bit organisiert. Jeweils 32 Bit breit sind die 14+2 universellen Arbeitsregister.<br />
<br />
Durch 32-Bit Verarbeitungsbreite, CISC Befehlssatz und Hardware MUL/DIV übersteigt die Verarbeitungsleistung des ZNEO das sonst übliche 8-Bit Controller Niveau deutlich. Sie liegt, bei gleicher Taktfrequenz, nahe der von ARM-7 Derivaten. Die Struktur und der Komplexitätsgrad des ZNEO ähneln aber mehr den aktuellen 8-Bit Mikrocontrollern.<br />
<br />
== Alleinstellungsmerkmal ==<br />
Das unbeschränkte Zilog Entwicklungspaket mit integriertem Editor, C-Compiler, Assembler, In-System-Debugger sowie Programmier- und Debugging-Kabel ist für 30$ zu haben.<br />
<br />
Auf den ersten Blick findet man das auch bei anderen Controller Familien. Beim zweiten Hinschauen fehlt aber entweder die Möglichkeit zum Debugging oder die Codegröße ist begrenzt.<br />
<br />
Von Quereinsteigern völlig unterschätzt, das Debugging. Damit verbringt man die meiste Zeit und deshalb ist es das Wichtigste am Programmieren.<br />
Einen Controller ohne In-System Debugging zu programmieren ist so frustrierend und uneffizient wie das Arbeiten in Maschinensprache; Binärzahl für Binärzahl.<br />
<br />
== Bauformen ==<br />
Der ZNEO ist als 64-pin LQFP, 68-pin PLCC, 80-Pin QFP und 100-pin LQFP verfügbar. Die 80- und 100-poligen Versionen beinhalten, bis auf eine Ausnahme, ein paralleles Adress-/Daten-Interface zu externen Komponenten.<br />
<br />
http://www.mikrocontroller.net/wikifiles/8/8f/ZilogZneoSmall.png<br />
<br />
Für Prototyping und Hobby ist die sockelbare 68-pin PLCC Version (Z16F2810VH) mit 128kB Flash, 4kB RAM besonders interessant. Diese ist das Äquivalent der geometrisch kleineren 64-pin LQFP Version Z16F2810AG.<br />
<br />
Hier eine optimierte Eagle Library mit den 64- und 68-Pin Bauformen: [http://www.mikrocontroller.net/wikifiles/6/63/ZilogZneoSmall.zip ZilogZneoSmall.zip]<br />
<br />
== Eckdaten ==<br />
Der Betriebsspannungsbereich ist 2,7-3,6V. Erwähnenswert ist dabei, dass alle rein digitalen IO Pins externe Spannung bis 5,5V vertragen.<br />
Die intern erzeugte ADC Referenzspannung von 2V steht ab 3V Betriebsspannung zur Verfügung.<br />
<br />
Getaktet wird der Controller vom internen Oszillator mit 5.5MHz oder 32kHz, internen Watchdog Timer oder externen Oszillator/Quarz/Resonator/RC-Glied. Die maximale Taktfrequenz ist 20MHz.<br />
<br />
Standard Baugruppen sind drei 16-Bit Timer mit PWM, ein dedizierter 6x1/3x2-Kanal PWM Timer, zwei LIN-UART, Infrarot Encoder/Decoder, ESPI, I2C, Watchdog, 12-Kanal 10-Bit ADC, ein Komparator, ein OPV, 4-Kanal DMA, VBO und PO-Reset.<br />
<br />
Der Adressraum des ZNEO ist linear und wird mit 24 Bit adressiert. Der C-Compiler reserviert (einstellbar) die untersten 32kB für „const“ Flash-Daten. Diese werden, Befehlsbreite sparend, mit 16 Bit Adresse angesprochen. Oberhalb des nachfolgenden Codebereichs werden Flash-Daten mit 24 Bit adressiert (far).<br />
<br />
Die ZNEO Versionen ohne paralleles Interface haben alle 128kB Flash. Bei den übrigen findet man 128, 64 oder 32kB. Dem zur Seite stehen meist 4kB RAM.<br />
Der Flash Speicher ist in 2kB Bänken organisiert die getrennt gelöscht werden können. Damit ist die Emulation des fehlenden EEPROM möglich.<br />
Extern, via parallelem Interface, angebundener Flash Speicher kann wie interner Flash Speicher per Programmierkabel geladen werden.<br />
Bei gleichem C-Programm benötigt der ZNEO im Vergleich zu RISC Mikrokontrollern nur rund 50 Prozent des Flash Speicher.<br />
<br />
== Entwicklungshardware ==<br />
Als komplettes Paket empfiehlt sich das Zilog Contest Kit ZNEOCTK0100KIT, verfügbar bei Mouser.com, für 49,99$. Es besteht aus USB Smart Kabel, Universal-Netzteil und ZNEO Contest Board mit Z16F2811FI (128kByte Flash), I2C EEPROM (PCA8550), SPI Thermometer (DS1722) und Punktmatrix LED Display.<br />
<br />
Ebenfalls 128kByte intern Flash bietet das Zilog Entwicklungs-Kit Z16F2800100ZCOG für 99,95$. Es basiert auf dem 100-Pin Z16F2811AL20SG, externem Flash 1Mx16, externem SRAM 256Kx16, 3 LEDs, RS232, irDA, USB Smart Kabel und Universal-Netzteil. Diese Karte kann allein stehend oder als Prozessor Modul für das modulare Entwicklungssystem ZGENPRP0100MDS genutzt werden.<br />
<br />
Ein Entwicklungsboard kann man aber auch leicht selbst bauen. Notwendig sind eine Lochraster Karte, der Z16F2810VH im PLCC-68 Gehäuse, die passende Fassung für Lochraster, eine 3x2 Stiftleiste für den Anschluss des USB Smart Kabel und einige Kleinteile. Verdrahtet wird das Ganze mit 0,2-0,3mm Fädeldraht. Zur Stromversorgung reichen 4 Rundzellen.<br />
<br />
http://www.mikrocontroller.net/wikifiles/c/ca/Z16F2810VH_Basic.png<br />
<br />
Zum Programmieren und Debuggen benutzt man das preisgünstige USB Smart Kabel ZUSBSC00100ZACG für 29,95$ oder das ähnliche Ethernet Smart Kabel ZENETSC0100ZACG für 69,99$.<br />
Die bei Kauf meist veraltete Firmware des Smart Kabel sollte auf den neuesten Stand gebracht werden. Aktuelle Firmware Versionen befindet sich, mit einer genauen Update Vorschrift, im Ordner des Zilog Development Systems ZDSII\bin\firmware.<br />
Nicht unerwähnt soll bleiben, dass diese beiden Programmier- und Debugging-Kabel auch mit den 8-Bit Mikrokontrollern der Z8 Encore! Reihe zusammenarbeiten.<br />
<br />
http://www.mikrocontroller.net/wikifiles/8/85/ZilogSmartKabel.png<br />
<br />
== Entwicklungssoftware ==<br />
Das Zilog Developer Studio II (ZDS II) ist ein integriertes Entwicklungs- und Debug-Tool für Assembler und C. Zum Zeitpunkt dieser Niederschrift in der Version 4.11.1. Es ist kostenlos downloadbar und ohne Beschränkungen.<br />
<br />
ZDS II gestaltet das Anlegen und Parametrieren von Projekten sehr einfach. Alle Optionen für Assemblieren, Kompilieren, Linken und Debuggen werden zusammengeklickt. Manuelles Bearbeiten eines Makefile ist nicht notwendig.<br />
<br />
Leider ist es ein halbherzig entwickeltes Programm mit einigen Bugs.<br />
Die Ursachen liegen im Editor- und Disassembler-Fenster. Beide vertragen nur bedingt Umlaute oder Sonderzeichen wie das hochgestellte °. Bei Umlauten kann man das Problem durch Kopieren und Einfügen umgehen, eine befriedigende Lösung ist das aber nicht. Eine weiter Unsicherheit sind die deaktivierbaren Variablen-Popups während des Debuggens.<br />
Trotzt dieser Kritikpunkte ist das Programm gut zu bedienen und auf Grund seiner Geradlinigkeit kann man nach kurzer Zeit produktiv damit arbeiten.<br />
<br />
Das Help-System ist durch die vielen Controllerfamilien etwas unübersichtlich aber vollständig und hilfreich.<br />
<br />
Die Hardware spezifische C-Header Datei enthält leider keine symbolischen Konstanten für die Bits der Konfigurations-Register des Controllers. Abhilfe schaffen nachfolgende C Dateien im ZIP: <br />
[http://www.mikrocontroller.net/wikifiles/a/ac/ZneoHeader_2009-01-27.zip ZneoHeader_2009-01-27.zip]<br />
<br />
Das Flashen des Controllers erfolgt direkt aus ZDS II. 10kB brauchen 8 Sekunden. 100kB sind in 40 Sekunden geladen.<br />
<br />
Im debugging Modus des Zielsystems kann man das Programm in getrennten Fenstern auf Hochsprach- und/oder Assembler-Ebene Schritt für Schritt abarbeiten und untersuchen. Der Einzelschritt-Betrieb reagiert relativ träge. Dafür bleibt der Debugger aber im Thread und springt nicht unkontrolliert zu Interrupts. 4 Breakpoints sind gleichzeitig möglich.<br />
<br />
Bei Programm-Unterbrechung werden der Callstack, Speicherinhalt, die Arbeits- und Konfigurations-Register, alle lokalen Variablen der aktuellen Funktion und die gewünschten globalen Variablen angezeigt. Natürlich kann man alle diese Werte auch verändern; globale Variable sogar während des Programmlaufs.<br />
<br />
Für die Produktion existiert ein separates und gutes Flash Programm SFP.<br />
<br />
== Bezugsmöglichkeiten ==<br />
* [http://www.digikey.com/ Digi-Key]<br />
* [http://www.mouser.com/ Mouser Electronics]<br />
== Dokumentation, Tools ==<br />
* [http://www.zilog.com/ Zilog Incorporation]<br />
* [http://www.mikrocontroller.net/articles/Zilog_ZNEO_Bootloader ZNEO Bootloader (free)]<br />
* [http://nuttx.sourceforge.net/ NuttX RTOS (free)]<br />
<br />
[[Category:Mikrocontroller]]</div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Datei:ZneoHeader_2009-01-27.zip&diff=34020Datei:ZneoHeader 2009-01-27.zip2009-01-27T22:52:02Z<p>Simulator: </p>
<hr />
<div></div>Simulatorhttps://www.mikrocontroller.net/index.php?title=Zilog&diff=34019Zilog2009-01-27T22:50:28Z<p>Simulator: /* Siehe auch */</p>
<hr />
<div>==Übersicht Zilog Mikrocontroller==<br />
<br />
===Encore!===<br />
''english encore = deutsch Zugabe''<br />
<br />
* '''Z8 Encore!''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=5&parent_id=2 Link]): 256 Bytes SRAM, bis 12 KB Flash-ROM, 20 MHz, keine Communication Interfaces<br />
<br />
* '''Z8 Encore! XP''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=6&parent_id=2 Link]): bis 4KB SRAM, bis 64 KB Flash-ROM, 5/20 MHz, Communication Interfaces [[UART]], [[SPI]], [[I2C]], teilweise [[IrDA]]. Beispiel [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProductDetails&familyId=6&productId=Z8F6421 Z8F6421]<br />
<br />
* '''Z8 Encore! MC''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=7&parent_id=2 Link]): für Brushless DC-Motor Anwendungen<br />
<br />
* '''[[ZNEO]]''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=8&parent_id=2 Link]): 16-bit [[CISC]]<br />
<br />
* '''Encore! 32''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=124&parent_id=2 Link]): 32-Bit ARM9 [[RISC]], [[SoC]]<br />
<br />
===eZ80===<br />
''english acclaim = deutsch Beifall''<br />
<br />
* '''EZ80 ACCLAIM''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=119&parent_id=77 Link]): <br />
<br />
* '''EZ80 ACCLAIM PLUS!''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=130&parent_id=77 Link])<br />
<br />
===Classic===<br />
<br />
* '''[[Z8]]''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=13&parent_id=113 Link])<br />
<br />
* '''Z180''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=19&parent_id=113 Link])<br />
<br />
* '''[[Z80]]''' ([http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showFamilyDetails&familyId=20&parent_id=113 Link])<br />
<br />
==Siehe auch==<br />
* [[Zilog Encore Experimentierplatine]] für [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProductDetails&familyId=6&productId=Z8F6421 Z8F6421]<br />
* [[Zilog ZNEO Bootloader]]<br />
<br />
==Weblinks==<br />
* [http://www.jandspromotions.com/zilog2004/ Zilog 2004 Flash Nets Cash Design Contest] (eZ80 Acclaim!)<br />
* [http://www.jandspromotions.com/zilog2003/ ZiLOG Flash for Cash Z8 Encore®! International Design Contest] (Z8 Encore! XP)<br />
* [http://www.zilog.com/docs/z8encorexp/devtools/fl0060.pdf Zilog Z8 Encore! XP 4K Series Development Kit] (PDF)<br />
<br />
[[Category:Mikrocontroller]]</div>Simulator