Mikrocontroller.net - Benutzerbeiträge [de]

Entscheidung Mikrocontroller

2009-02-20T23:40:48Z

Mah: /* [http://www.atmel.com/ Atmel] */

[[Category:Mikrocontroller]]
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]]

== Verfügbarkeit ==
* Während man manche Mikrocontroller an jeder Straßenecke bekommt, sind andere nur in großen Stückzahlen und mit Gewerbenachweis erhältlich. Dazu einfach mal in die Kataloge der einschlägigen Privatkundenhändler schauen. Dabei auch darauf achten, dass der gewünschte Controller auch in der richtigen Bauform erhältlich ist (DIP, TQFP, MLF,usw.), s.u.
* Ab und zu kündigen Hersteller ein neues Modell an (und veröffentlichen das Datenblatt dazu), können aber erst ein Jahr später nennenswerte Stückzahlen liefern. Also den Controller nicht einfach anhand der Übersichten beim Hersteller aussuchen, sondern überprüfen, was die Händler auch wirklich liefern können.
* Lebenszyklus: Kein Modell wird ewig hergestellt, deswegen sollte man überprüfen, ob der Hersteller vielleicht schon angekündigt hat, dass er ein bestimmtes Modell nicht mehr herstellen will. Die Hersteller schreiben dann z.B. "Mature Product (Not Recommended for New Designs)". Für Neuentwicklungen oder den Einstieg sollte man folgende Modelle nicht verwenden:
** AVR AT90-Reihe,
** AVR ATMega 103(L), 161(L), 163(L), 323(L).
* Für alle abgekündigten AVR-Controller gibt es jedoch pin- und funktionskompatible Nachfolger. Daher kommt es nur in den seltensten Fällen zu Problemen. Probleme können nur entstehen wenn ein Programm nur in kompilierter Version zur Verfügung steht.
* Dagegen sind Mikrocontroller der [[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.

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

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

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

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

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

== Bauformen ==
Neben den klassischen (bedrahteten) Bauformen setzt sich heutzutage [[SMD]] immer mehr durch. Manche Mikrocontroller sind nur noch in SMD-Bauformen erhältlich. Für SMD benutzt man üblicherweise geätzte Platinen oder Adapter/Sockel (die aber wieder extra kosten). Will man mit Lochrasterplatinen oder [[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.

Viele Mikrocontroller sind in verschiedenen Bauformen verfügbar. Nur in SMD verfügbar sind:
* MSP430 (Die kleinen sind mittlerweile auch als DIP erhältlich)
* AVR ATMega 64, 128, 169

In der klassischen (wenn auch in der Anzahl der verfügbaren IO-Pins limitiert) PDIP Bauform gibt es unter anderem:
* AVR ATMega 8, 16, 32
* viele 8051-Derivate, z.B. Atmel 89S8252

== Spannung ==
Während früher die meisten Mikrocontroller und die gesamte Peripherie mit 5V liefen, so gibt es heute auch alle möglichen anderen Varianten. Zu beachten ist:
* Controller und Peripherie müssen zusammenpassen. Man kann nicht einfach (ohne weitere Vorkehrungen) ein 3,3V-RAM an einen 5V-Controller anschließen und umgekehrt.
* Manche Controller besitzen, obwohl sie intern mit einer anderen Spannung arbeiten, 5V-kompatible IO-Pins (Beispiel: [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]]).
* Manche Controller brauchen zwei verschiedene Spannungen. Dies ist aber relativ selten, z.B. bei den [[LPC2000 Philips ARM7TDMI-Familie|LPC2100]].

* Billig-Netzteile liefern im Leerlauf manchmal deutlich mehr Spannung als angegeben, ein [[Standardbauelemente|Spannungsregler]] (z.B. 78xx) ist also Pflicht!
* Bei Batterien und Akkus sinkt die Spannung ab, wenn sie leerer werden. Braucht der Controller z.B. mindestens 2,7V, dann wird man mit zwei 1,5V-Batterien nicht lange Freude haben (außer man benutzt spezielle Schaltregler).

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

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

{| border=1 cellspacing=0
! Frequenz !! ATMega8 (2.7V) !! ATMega8 (5.0V) !! PIC16LF84A(2.0V) !! PIC16F84A (5.5V)
|-
! 32KHz
|62µA||80µA||45µA||-
|-
! 100KHz
|0,3mA||0,5mA||-||-
|-
!1MHz, 2MHz*
|1,5mA ||2,3mA||4mA||-
|-
!8MHz, 4MHz*
|5mA ||7/15mA**||-||4.5mA
|-
!16MHz, 20MHz*
| - ||20mA||-||20mA
|}

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

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

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

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

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

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.

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

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

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

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

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.

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

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

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

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

Ausgehend vom Quellcode/Assembler-Fenster kann man den Programmcode auf das Zielsystem laden, den Programmlauf starten und an beliebigen Stellen stoppen, das Programm zeilenweise abarbeiten, Variablen/Speicher/Register anzeigen und auch verändern. Diese Vorgänge werden bei modernen Debuggern mit wenigen Funktionstasten und Kontextmenü gesteuert.

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.

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.

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:

=== [http://www.atmel.com/ Atmel] ===

{| border="1"
|-
!System
!Preis
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2737 AVR JTAG ICE] Clone (wenige ATmega Typen)
| ~ 35€
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3891 AVR Dragon] (Debugging <= 32kB)
| ~ 55€
|-
| [http://www.keeelectronics.com/mkii.htm AVR JTAG ICE MKII - CN]
| ~ 85$
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3353 AVR JTAG ICE MKII] / Clone
| ~ 280€/160$
|-
| [http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4279 AVR ONE!]
| ~ 550€
|}

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

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.

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.

Bei AVR JTAG ICE MKII - CN clones sollte man genau auf die unterstütze Software-Umgebung achten - "AVR Studio supported" kann durchaus heissen: "avrdude is not supported".

Atmel [[AVR]] Dragon kann ATtiny, ATmega und AT32UC3x programmieren aber nur ATtiny und ATmega bis 32 kB Flash-Speicher Größe debuggen.

=== [http://www.microchip.com/ Microchip] ===

{| border="1"
|-
!System
!Preis
|-
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023805 MPLAB PICkit2 / PICkit2 Debug Express]
| ~ 30€/55€
|-
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340 MPLAB PICkit3 Debug Express]
| ~ 65€
|-
| [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]
| ~ 90€/40€
|-
| [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en537580 MPLAB ICD 3]
| ~ 190€
|}

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.

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.

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.

=== [http://www.zilog.com/ Zilog] ===

{| border="1"
|-
!System
!Preis
|-
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZUSBSC00100ZACG USB Smart Kabel]
| ~ 30$
|-
| [http://www.zilog.com/index.php?option=com_product&Itemid=26&mode=showProdDet&businessLine=1&familyId=6&productId=ZENETSC0100ZACG Ethernet Smart Kabel]
| ~ 70$
|}

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.

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

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

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

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

ARM GCC toolchain for Linux and Mac OS X

2009-01-19T08:43:12Z

Mah: /* Related websites */

'''Update (2007-04-20): added Mac OS X Intel version'''

This package is intended for and was tested with small ARM microcontrollers like LPC21xx, AT91SAM7, ST7, ADuC7000, but should work for any system supported by arm-elf. Take a look at the configuration of the components below to find out whether it suits your application.

== Content (Build 2) ==

This build is similar to Martin Thomas' WinARM package. The main difference to GNUARM is that in WinARM and this build Newlib is compiled with the option -DREENTRANT_SYSCALLS_PROVIDED, as recommended in Bill Gatliff's article "Porting and Using Newlib in Embedded Systems".

* Binutils 2.16.1 configured with <code>--target=arm-elf --enable-interwork --enable-multilib</code>
* GCC 4.1.0 with patched t-arm-elf, configured with <code>--target=arm-elf --enable-interwork --enable-multilib --enable-languages="c,c++" --with-newlib</code>
* Newlib 1.14.0 configured with <code>--target=arm-elf --enable-interwork --enable-multilib</code> and <code>-DREENTRANT_SYSCALLS_PROVIDED</code>
* GDB 6.4 configured with <code>--target=arm-elf --enable-interwork --enable-multilib</code>

Everything is built with <code>--prefix=/usr/local/arm</code>. The Linux version is compiled with Debian Sarge, the Mac OS X PPC version with 10.3 (Panther), the Mac OS Intel Version with 10.4 (Tiger). All binaries are stripped. The build process on Linux and Mac OS X is identical.

== Download ==

* [http://www.mikrocontroller.net/download/arm-toolchain-macosx-2.tar.bz2 Build 2 - Mac OS X PPC (23 MB)]
* [http://www.mikrocontroller.net/download/arm-toolchain-macosx-intel-2.tar.bz2 Build 2 - Mac OS X Intel (32 MB)] ([http://en.mikrocontroller.net/topic/104901 compiled by Darrik Spaude])
* [http://www.mikrocontroller.net/download/arm-toolchain-linux-2.tar.bz2 Build 2 - Linux (23 MB)]

== Installation ==

cd /tmp
# download
curl -O -C - http://www.mikrocontroller.net/download/arm-toolchain-macosx-2.tar.bz2
# extract
tar xjvf arm-toolchain-macosx-2.tar.bz2
# install
sudo mv arm /usr/local/
# add /usr/local/arm/bin to your path permanently
echo 'export PATH=/usr/local/arm/bin:$PATH' >> ~/.profile

== Support forum ==

If you have any questions regarding this toolchain build or want to discuss ARM-GCC programming in general, please visit [http://en.mikrocontroller.net/ the forum].

== Related websites ==

* [http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/ WinARM, ARM projects]
* [http://www.gnuarm.com GNUARM]: Linux, Windows and outdated Mac OS X builds of GCC+Newlib+GDB
* [http://zylin.com/gccbinary.html Zylin.com] GCC+GDB binaries for arm-elf, cortex, xscale, mips-elf, powerpc-eabi targets, platforms, hosted on Windows MinGW, Crossbuild Windows hosted from Debian, Cygwin,Linux,Mac x86 or Mac PowerPC

[[Kategorie:ARM]]

AVR-GCC

2009-01-15T11:50:58Z

Mah: /* Mac OS X */

[[Category:AVR]]

AVR-GCC ist ein kostenloser [[C]]-Cross-[[Compiler]] für [[AVR]]-[[Mikrocontroller]].

AVR-GCC kann von der Leistungsfähigkeit her mit kommerziellen [[Compiler]]n gut mithalten. Sogar C++-Programme sind möglich, in der aktuellen Fassung wird C++ jedoch nur eingeschränkt unterstützt (Stand 6/2007).

== Bestandteile ==

Die Toolchain (Werkzeugsammlung) besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen (typischerweise als Aufrufe von make mit Parameter, vgl. [[AVR-GCC-Tutorial]]).

Die Bestandteile im einzelnen:
* Binutils: Assembler, Linker und weitere Hilfsprogramme.
* GCC: Der eigentliche C(++)-Compiler.
* AVR-LIBC: Die C-Standardbibliothek mit AVR-spezifischen Headerdateien und Funktionen.
* ([[AVRDUDE]]: universelle AVR-Programmiersoftware, kein eigentlicher Teil der Toolchain, aber oft verwendet)

== Installation ==

=== Linux/Unix ===

Wenn keine aktuelle AVR-GCC-Version als Paket für die verwendete Distribution zur Verfügung steht, dann können sich [[Unix]]/[[Linux]]-Nutzer den Sourcecode herunterladen und selbst kompilieren. Schritt-für-Schritt-Anleitungen gibt es [http://www.nongnu.org/avr-libc/user-manual/install_tools.html hier] und [http://www.roboternetz.de/wissen/index.php/Avr-gcc_und_avrdude_installieren hier]. Empfehlenswert ist auch [http://cdk4avr.sf.net CDK4AVR], das die entsprechenden tools als einfach installierbare Linux-Pakete bereitstellt (distributionsunabhängig als .tar.gz). Weitere Tipps zur AVR Programmierung unter Linux stehen im Artikel [[AVR und Linux]].

=== Mac OS X ===
Die beste fertige Toolchain ist [http://www.obdev.at/products/avrmacpack/index.html AVR MacPack]. Diese enthält auch die avr-libc, avrdude und avarice. Leider gab es bei Mac OS 10.5.6 eine tiefgreifende Änderung beim fork()-Systemcall, der bewirkt, dass avarice mit JTAGICE mkII und Dragon nicht funktioniert. Geräte mit Serial-USB-Konvertern (AVRISP clones etc) funktionieren dagegen problemlos.

Wer die Toolchain von Hand bauen möchte kann das natürlich auch tun, dazu einfach den unter "Linux/Unix" verlinkten Anleitungen folgen. Unter [[Mac OS X]] muss man dazu zuerst die [http://developer.apple.com/Tools/ Apple Developer Tools] installieren.

Teile der Toolchain (avr-libc und avrdude) kann man mit dem Paketsystem [http://www.macports.org/ MacPorts] installieren. Die Compiler-Toolchain kann man dann installieren, indem man folgenden Befehl im Terminal eingibt:

sudo port install avr-libc

Das Programmiertool avrdude bekommt man genauso:

sudo port install avrdude

Weblinks:

* [http://tinkerlog.com/2007/09/29/programming-avr-with-a-macbook/ Programming AVR with a MacBook] (engl.)
* [http://www.ladyada.net/library/avrdevtut/setup-mac.html AVR Tutorial from Lady Ada] (engl.)
* [http://www.obdev.at/products/avrmacpack/index.html AVR MacPack]
* [http://www.digithink.com/OSX-AVR OSX-AVR (nicht mehr aktuell)]

=== Windows ===

Für MS-Windows gibt es das fertig kompilierte Softwarepaket [[WinAVR]].

== Entwicklungsumgebungen ==

Win32:
* [[AVR-Studio]]: ab Version 4.12 mit WinAVR-Unterstützung, integrierter Simulator, Debugger, rudimentäre Projektverwaltung
* Programmers-Notepad: wird bei [[WinAVR]] mitgeliefert, ein guter Editor mit einer rudimentären Projektverwaltung
* [http://www.myavr.info/download/benutzerhandbuch_sisy_avr.pdf SiSy-AVR]: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.

Platformunabhängig:
* [http://www.eclipse.org/ Eclipse] mit CDT und dem [http://avr-eclipse.sourceforge.net/index.html AVR Eclipse Plugin]

== Bibliotheken / Libraries ==

Die [http://www.nongnu.org/avr-libc/ avr-libc] ist die gebräuchliche "Laufzeitbibliothek" zum avr-gcc C-Compiler, welche den Zugriff auf die AVR-Hardware erheblich erleichtert. Die offizielle Dokumentation zur avr-libc mit vielen Hinweisen auch zum Compiler avr-gcc und verschiedener Tools (z.B. [[AVRDUDE]]) findet man [http://www.nongnu.org/avr-libc/user-manual/index.html hier].

Auch die [http://hubbard.engr.scu.edu/embedded/avr/avrlib/ Procyon AVRlib] enthält nützlichen Code z.B. für UART, LCD,.... Bei der Procyon AVRlib ist die Lizenz zu beachten (in Kurzform: man muss dritten auf Verlangen den gesamten Quellcode der Firmware zur Verfügung stellen, falls Teile der Procyon Bibliothek genutzt werden).

Zum Zugriff auf interne Funktionen oder externe Peripherie existieren einige fertige Komponenten. Z.B. "Projects"-Bereich von [http://www.avrfreaks.net/ avrfreaks.net] (Anmeldung erforderlich (kostenlos)).

Die Erstellung eigener Bibliotheken ist im Artikel [[Libraries]] erklärt.

== Tipps & Tricks ==

Eine (hoffentlich wachsende) Liste mit einigen Hinweisen:

* Keine "antiken" Versionen verwenden. Für MS-Windows-Nutzer: aktuelles WinAVR installieren. Für Linux/Unix-Nutzer: letzte stabile Version selbst kompilieren oder aus "Distribution-Packages" installieren (z.B. [http://cdk4avr.sourceforge.net/ cdk4avr]).

* Bei Problemen zuerst in die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Anleitung] der avr-libc''' schauen. Insbesondere die FAQ lesen.

* Sicherstellen, dass der MCU-Parameter (zum Compiler/Linker, meist im Makefile defniert) mit dem Zielprozessor übereinstimmt.

* [[AVR-GCC-Tutorial]] in diesem Wiki lesen.

* Im Zweifel '''nicht INTERRUPT(...) sondern SIGNAL(...)''' nutzen. In neueren Versionen der avr-libc wurde '''ISR''' als Ersatz für SIGNAL eingeführt und sollte genutzt werden (SIGNAL und INTERRUPT werden langfristig entfallen). Darauf achten, dass die Vektor- bzw. Signal-Namen ("Parameter") zu ISR bzw. SIGNAL (und INTERRUPT wenn denn unbedingt erforderlich) richtig geschrieben sind. Die Namen sind in der in der entsprechenden Header-Datei (ioxxx.h) für den Controller und der avr-libc-Dokumenation aufgelistet. Im Zweifel den erzeugten Interrupt-Vektor im Assembler-Listing prüfen, es darf '''kein''' SIG_''xxx'' oder xxx_vect mehr zu sehen sein, sondern _vector_''N'' (wobei ''N'' eine Zahl ist). Neuere Versionen der avr-gcc zeigen eine Warnung, falls etwas falsch geschrieben wurde, ältere Versionen nicht.

* '''Zugriff auf Daten(-Tabellen) im Programmspeicher''' (Flash) erfolgt über Program-Space-Funktionen (pgm_read*). Lediglich die Definition einer Variablen/eines Feldes mit dem PROGMEM Attribut zu versehen, reicht (im Gegensatz zu Codevision, IAR, Imagecraft) nicht aus.

* Nicht alle AVRs werden vollständig von der avr-libc bzw. dem Compiler unterstützt. Bei Problemen hilft oft ein Blick in den erzeugten Assembler-Code. Die Anzahl der unterstützen Controller steigt jedoch mit Version zu Version von binutils, avr-libc und avrdude. Evtl. reicht einfach ein Update auf neuere Software-Versionen (z.B. im jeweils aktuellen WinAVR-Packet).

* '''inp(), outp(), sbi() und cbi()''' werden in der aktuellen Bibliotheksversion nicht offiziell unterstützt (man muss eine spezielle Header-Datei einbinden(deprected.h). Es wird schon seit längerem empfohlen, diese Makros nicht mehr zu nutzen. Einige Anleitungen sind in diesem Punkt veraltet. Mit halbwegs aktuellen avr-gcc/avr-libc-Versionen kann einfach z.B. DDRB=0xfe bzw. foo=PINB geschrieben werden. Mit PORTB |= _BV(1) setzt man PORTB.1, mit PORTB &= ~_BV(1) löscht man es wieder, mit PORTB ^= _BV(1) kann man es umschalten (_BV(x) entspricht dabei (1<<x)). Die ersten beiden Varianten erzeugen bei eingeschalteter Optimierung und passenden Parametern (wie hier im Beispiel Register im "unteren" Speicherbereich) die SBI bzw. CBI Prozessorbefehle.

* Mit dem Tool '''avr-nm''' erhält man eine Übersicht über die Platzausnutzung in der erzeugten ELF-Datei bzw. dem damit gefüllten AVR. Das Tool wird per Kommandozeile mit <tt>avr-nm --size-sort --print-size <name of your ELF file></tt> aufgerufen. Alle Symbole mit einem "T" (globale Funktionen), "t" (statische Funktionen) und letztlich auch mit einem "D" oder "d" (globale bzw. statische Daten, die haben ihre Initialisierungswerte im ROM) betreffen das FLASH-ROM. "B" und "b" brauchen ausschließlich RAM (werden beim Start mit 0 initialisiert). Die erste Spalte ist die Adresse des Symbols, die zweite ist die Größe (beides hexadezimal). (nach [http://www.mikrocontroller.net/topic/59960#467920 Forenbeitrag] von Jörg Wunsch)

* Mit dem Tool '''avr-size''' erhält man eine Übersicht über den Platzbedarf in den text, data und bss Sektionen innerhalb der ELF Binärdatei. Die Sektionen text und data benötigen Platz im FLASH-ROM und die Sektionen data und bss benötigen zur Laufzeit Platz im SRAM.

== Siehe auch ==
* [[AVR-GCC-Tutorial]]
* [[AVR-GCC-Codeoptimierung]]
* [[GCC: unbenutzte Funktionen entfernen]]
* [http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna AVR-GCC Interna]

== Weblinks ==
* [http://winavr.sourceforge.net/install_config_WinAVR.pdf Tutorial von C. O'Flynn und E. Weddington] Einstieg in die Nutzung des avr-gcc unter MS-Windows mit WinAVR (englisch)
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml AVR-GCC und Linux]
* [http://www.mikrocontroller.net/forum/list-2-1.html GCC-Forum auf mikrocontroller.net]