AVR-GCC: Unterschied zwischen den Versionen

Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
Wechseln zu: Navigation, Suche
 
(34 dazwischenliegende Versionen von 18 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
avr-gcc ist ein freier [[C]]-Cross-[[Compiler]] für [[AVR]]-[[Mikrocontroller]].


AVR-GCC ist ein kostenloser [[C]]-Cross-[[Compiler]] für [[AVR]]-[[Mikrocontroller]].
avr-gcc kann von der Leistungsfähigkeit kommerzieller [[Compiler]] gut mithalten. Sogar C++-Programme sind möglich; in der aktuellen Fassung wird C++ jedoch nur eingeschränkt unterstützt (Stand 3/2012).
 
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 ==
== 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 Toolchain (Werkzeugsammlung) besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung, siehe [[AVR-GCC-Tutorial/Exkurs Makefiles|AVR-GCC-Tutorial: Exkurs Makefiles]].  


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


== Installation ==
== Installation ==
Zeile 18: Zeile 17:
=== Linux/Unix ===
=== 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].
Atmel bietet die [http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an.


Das [http://www.femtoos.org FemtoOS]-Paket beinhaltet Scripte zum automatischen Herunterladen und Bauen einer aktuellen AVR-GCC Version.
Wenn keine aktuelle avr-gcc-Version als Paket (Paketname ist, zumindest bei Debian, gcc-avr) für die verwendete Distribution zur Verfügung steht, dann können sich [[Unix]]/[[Linux]]-Nutzer den Sourcecode herunterladen und selbst kompilieren, dazu gibt es Schritt-für-Schritt-Anleitungen<ref>[http://www.nongnu.org/avr-libc/user-manual/install_tools.html AVR-Libc: Building and Installing under Linux, FreeBSD, and Others]</ref><ref>[http://www.roboternetz.de/wissen/index.php/Avr-gcc_und_avrdude_installieren www.roboternetz.de: avr-gcc und avrdude installieren]</ref>.


Empfehlenswert ist auch [http://cdk4avr.sf.net CDK4AVR], das die entsprechenden tools als einfach installierbare Linux-Pakete bereitstellt (distributionsunabhängig als .tar.gz). Leider ist das Projekt schon etwas älter, im [http://www.mikrocontroller.net/topic/130972 Forum] findet sich ein Beitrag, aktuellere Sourcen mit den entsprechenden Patches zu versehen und zu kompilieren. Patches zu den Binutils und GCC Sourcen sind unumgänglich, da die offiziellen Sourcen aufgrund des Umfangs an Prozessortargets den aktuellsten Entwicklungen hinterherhinken und damit bereits bekannte Fehler eventuell noch nicht behoben sind. Weitere Tipps zur AVR Programmierung unter Linux stehen im Artikel [[AVR und Linux]].
Das [http://www.femtoos.org FemtoOS]-Paket beinhaltet Scripte zum automatischen Herunterladen und Bauen einer avr-gcc Version 4.3.3.
 
Empfehlenswert ist auch [http://cdk4avr.sf.net CDK4AVR], das die entsprechenden Tools als einfach installierbare Linux-Pakete bereitstellt. Leider ist das Projekt schon etwas älter, im Forum findet sich ein [http://www.mikrocontroller.net/topic/130972 Beitrag], aktuellere Sourcen mit den entsprechenden Patches zu versehen und zu kompilieren. Patches zu den Binutils und GCC-Sourcen sind unumgänglich, da die offiziellen Sourcen aufgrund des Umfangs an Prozessortargets den aktuellsten Entwicklungen hinterherhinken und damit bereits bekannte Fehler eventuell noch nicht behoben sind. Weitere Tipps zur AVR-Programmierung unter Linux stehen im Artikel [[AVR und Linux]].


=== Mac OS X ===
=== Mac OS X ===
Die beste fertige Toolchain ist das [http://www.obdev.at/crosspack/ Crosspack]. Dieses 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.  
Die beste fertige Toolchain ist das [http://www.obdev.at/crosspack/ Crosspack]. Dieses 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.
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:
Teile der Toolchain (AVR-Libc und avrdude) kann folgendermaßen installieren:
 
==== Mit MacPorts ====
Wenn man [http://www.macports.org/ MacPorts] benutzt kann man folgendes in das Terminal eingeben, um den Toolchain zu installieren:


  sudo port install avr-libc
  sudo port install avr-libc
Zeile 36: Zeile 40:


  sudo port install avrdude
  sudo port install avrdude
==== Mit Homebrew ====
Mit dem neueren Tool [http://brew.sh Homebrew] funktioniert das folgendermaßen:
avrdude kann sofort installiert werden:
brew install avrdude
Für den restlichen Toolchain muss man erst ein 'Tap' hinzufügen:
brew tap osx-cross/avr
und kann dann den eigentlichen Toolchain installieren:
brew install avr-libc


Weblinks:
Weblinks:
Zeile 44: Zeile 63:
* [http://www.digithink.com/OSX-AVR OSX-AVR (nicht mehr aktuell)]
* [http://www.digithink.com/OSX-AVR OSX-AVR (nicht mehr aktuell)]
* [http://www.definefalsetrue.com/index.php/Mac-OS-X/bootfeedx.html BootFeedX Bootloaderfrontend]
* [http://www.definefalsetrue.com/index.php/Mac-OS-X/bootfeedx.html BootFeedX Bootloaderfrontend]
* [http://github.com/osx-cross/homebrew-avr/ homebrew-avr]


=== Windows ===
=== Windows ===


Für MS-Windows gibt es das fertig kompilierte Softwarepaket [[WinAVR]].
Man kann sich auch für Windows den GCC selbst bauen oder man sucht von anderen erstellte Binaries.
 
Atmel bietet die [http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx Atmel AVR Toolchain] in verschiedenen Versionen zum Herunterladen an. Allerdings ohne "make".
 
Der alte Klassiker [[WinAVR]] wird seit 2010 nicht mehr gepflegt und funktioniert
ab Windows 8 nur noch eingeschränkt.
 
Die Firma SysProgs bietet aktuelle Versionen der [http://gnutoolchains.com GNU Toolchain]
einschließlich "make" für viele Systemarchitekturen zum Download an.
 
==== Selbst bauen ====
 
Zuerst sei einmal die offizielle (englische) Anleitung genannt: [http://www.nongnu.org/avr-libc/user-manual/install_tools.html Building and Installing avr-gcc]
 
Das hier ist die etwas ausführlichere Beschreibung, die mir Johann L. gegeben hat, damit ich meinen Compiler erstellen konnte. Der Post dazu findet sich [https://www.mikrocontroller.net/topic/384825?goto=4394391#4394606 hier].
 
Zuerst einmal braucht man am besten ein Linux, zum Beispiel ein aktuelles Ubuntu. dort müssen diverse Programme wie gcc, autoconf, subversion usw. installiert sein. Wenn etwas fehlt meckert configure, das einfach aufmerksam lesen und dann die Programme nachinstallieren. Danach erneut configure aufrufen.
Um die Toolchain für Windows zu bauen brauchen wir noch mingw32 (aktueller Name in den meisten Paketquellen: mingw32-w64-gcc oder gcc-w64-mingw32). Eventuell findet sich das in den Paketquellen eurer Distribution, sonst kann ich auf [http://www.blogcompiler.com/2010/07/11/compile-for-windows-on-linux/ diese Seite] verweisen.
 
===== Vorbereitungen =====
Wie schon gesagt brauchen wir ein Linux, zum Beispiel in einer VM. Ein minimales Linux-Hintergrundwissen wären auch gut, aber es geht notfalls (Google & co. sind die Freunde) auch ohne.
'''Achtung:''' Auf diesem Linux darf kein avr-gcc und keine avr-libc vorhanden sein!
Dazu brauchen wir die folgende Software:
* GNU Binutils: [https://www.sourceware.org/binutils/ Download], am besten die neueste Version (runter scrollen, aktuell ist 2.27)
* GCC Sourcen: [https://gcc.gnu.org/ Download], diese sollten aus dem svn kommen (svn co svn://gcc.gnu.org/svn/gcc/branches/''branchname'' gcc ,mit ''branchname'' gcc-''version''-branch, aktuell ist gcc-6-branch) oder aus dem aktuellen ''trunk'' (svn co svn://gcc.gnu.org/svn/gcc/trunk).
* Die AVR-libc: [http://download.savannah.gnu.org/releases/avr-libc/ Download]. ''Achtung:'' Ab gcc-Version 5 muss mindestens eine avr-libc-Version >= 2.0.0 verwendet werden. Ältere GCCs brauchen natürlich auch eine avr-libc vor dieser Version.
 
Alles herunterladen und entpacken.
 
Zu den Downloads kommen dann noch 2 Umgebungsvariablen:
<syntaxhighlight lang="bash">
$ PREFIX=$HOME/local/avr
$ export PREFIX
$ PATH=$PATH:$PREFIX/bin
$ export PATH
</syntaxhighlight>
Damit legt ihr das Installationsverzeichnis fest und fügt auch gleich das Verzeichnis für die ausführbaren Dateien zum Pfad hinzu.
 
Im Folgenden gehe ich von diesem Ordner-Layout aus:
<pre>
$HOME
|
+ BuildToolchain
  |
  + Downloads
  |  |
  |  + binutils
  |  + gcc
  |  + avr-libc
  |
  + buildLinux
  |  |
  |  + binutils
  |  + gcc
  |  + avr-libc
  |
  + buildWindows
      |
      + binutils
      + gcc
</pre>
 
===== Erstellen der Binutils =====
Wechselt in das Verzeichnis BuildToolchain/buildLinux/binutils.
Von dort aus werden wir die binutils konfigurieren und erstellen.
 
'''Achtung:''' man darf weder GCC noch die Binutils in einem Verzeichnis innerhalb des Quellordners der Downloads konfigurieren, sonst kommen wirre Fehler. Wer sich an die Anleitung hält kann diesen Fehler (fast) nicht machen.
 
Also, wir sind soweit. Jetzt geht es ans Konfigurieren der binutils und danach ans kompilieren, aber das ist ganz leicht:
<syntaxhighlight lang="bash">
$ ../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls
</syntaxhighlight>
Wenn configure fehlende Programme meldet: nachinstallieren und erneut versuchen.
<syntaxhighlight lang="bash">
$ make
$ make install
</syntaxhighlight>
 
Damit sind die binutils für Linux fertig. Ihr könnt nachkontrollieren, ob die binutils da sind: Im Ordner $PREFIX/bin sollten sich die Dateien befinden, darunter avr-objcopy, avr-as, avr-size, etc.
 
===== Erstellen vom GCC =====
Als erstes muss sich der GCC noch ein paar zusätzliche Dateien herunterladen, das geschieht automatisch mit dem Befehl (ausgeführt in BuildToolchain/Downloads/gcc):
<syntaxhighlight lang="bash">
./contrib/download_prerequisites
</syntaxhighlight>
Wechselt ins Verzeichnis BuildToolchain/buildLinux/gcc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$PREFIX --target=avr \
    --enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2
$ make
$ make install
</syntaxhighlight>
 
===== Erstellen der avr-libc =====
Als erstes muss die avr-libs zum konfigurieren bereit gemacht werden:
Im Verzeichnis BuildToolchain/Downloads/avr-libc die Datei bootstrap ausführen
<syntaxhighlight lang="bash">
./bootstrap
</syntaxhighlight>
Danach wechselt ihr ins Verzeichnis BuildToolchain/buildLinux/avr-libc
Dort führt ihr das Folgende aus:
<syntaxhighlight lang="bash">
$ ../../Downloads/avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr
$ make
$ make install
</syntaxhighlight>
 
===== Testen unter Linux =====
So, jetzt seit ihr schon bei der Hälfte: Der Compiler läuft schon unter Linux!
Das testet ihr am besten schon mit ein paar einfachen LED-blink-Programmen, damit auch sichergestellt ist, dass bis hierhin alles geklappt hat.
Das einfachste und wichtigste Kommando dürfte sein
<syntaxhighlight lang="bash">
$ avr-gcc --version
</syntaxhighlight>
Dort sollte die Versionsnummer der GCC stehen. Wenn eine ältere Nummer dasteht, hab ihr entweder einen alten Download bemüht, oder eine andere Version vom avr-gcc war noch installiert.
Wenn der Fehler kommt, dass das Programm nicht gefunden werden kann, dann befindet sich avr-gcc nicht im PATH, das bedeutet ihr habt die Umgebungsvariablen nicht richtig gesetzt (siehe oben).
 
===== Bau für Windows =====
Ihr müsst keine neuen Dateien runter laden, lediglich die Programme nochmal etwas anders konfigurieren.
Die Schritte davor '''müssen''' jedoch ausgeführt werden!
 
Wechselt ins Verzeichnis BuildToolchain/buildWindows/binutils und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Download/binutils/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
    --host=plattform-w64-mingw32 --build=plattform-linux-gnu
$ make
$ make install
</syntaxhighlight>
Wobei ''plattform'' euer Ziel-System ist, also entweder i686 oder x86_64, je nach dem, was ihr für ein mingw installiert habt und ob ihr den Compiler für 32bit (i686) oder 64bit (x86_64) baut.
 
Wechselt ins Verzeichnis BuildToolchain/buildWindows/gcc und führt das Folgende aus
<syntaxhighlight lang="bash">
$ ../../Downloads/gcc/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
    --host=plattform-w64-mingw32 --build=plattform-linux-gnu --enable-languages=c,c++,lto --with-gnu-as \
    --with-gnu-ld --disable-shared --with-dwarf2
$ make
$ make install
</syntaxhighlight>
 
Wechselt ins Verzeichnis BuildToolchain/buildLinux/avr-libc und führt den folgenden Befehl aus:
<syntaxhighlight lang="bash">
$ make install prefix=$HOME/local/avr4win
</syntaxhighlight>
 
Eigentlich ist der Compiler auch "schon" fertig. Aber in den Binaries sind noch die gesamten Symbole enthalten, was die .exe-Dateien aufbläht. Um diese los zu werden, kann man einfach noch diesen Befehl ausführen:
<syntaxhighlight lang="bash">
$ find . -name '*.exe' -exec plattform-w64-mingw32-strip {} ';'
</syntaxhighlight>
 
Damit sollten ihr im Ordner $HOME/local/avr4win die gesamte Toolchain haben. Diesen Ordner müsst ihr nur noch auf euren Windows-PC kopieren.
Für das klassische WinAVR fehlt noch Programmers Notepad, sowie die Utility-Programme, vor allem avrdude und make. Diese kann man entweder seperat downloaden oder aus einer WinAVR-Installation kopieren. Die Versionen davon spielen keine Rolle.


== Entwicklungsumgebungen ==
== Entwicklungsumgebungen ==
Zeile 56: Zeile 227:
* [http://www.myavr.info/download/benutzerhandbuch_sisy_avr.pdf SiSy-AVR]: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.
* [http://www.myavr.info/download/benutzerhandbuch_sisy_avr.pdf SiSy-AVR]: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.


Platformunabhängig:
Plattformunabhängig:
* [http://www.eclipse.org/ Eclipse] mit CDT und dem [http://avr-eclipse.sourceforge.net/index.html AVR Eclipse Plugin]
* [http://www.eclipse.org/ Eclipse] mit CDT und dem [http://avr-eclipse.sourceforge.net/index.html AVR Eclipse Plugin]
* [[Code::Blocks]]: vielseitige, freie Entwicklungsumgebung für Windows und Linux
* [[Code::Blocks]]: vielseitige, freie Entwicklungsumgebung für Windows und Linux
* [http://www.netbeans.org/ Netbeans] in der C++ - Version mit [[WinAVR]] oder [[avr-gcc]] als Toolchain
* [http://www.netbeans.org/ Netbeans] in der C++ - Version mit [[WinAVR]] oder [[avr-gcc]] als Toolchain
Linux:
*[http://sourceforge.net/projects/kontrollerlab/?_test=b KontrollerLab] ist eine freie Entwicklungsumgebung für AVR momentan aber noch im Beta-stadium.


== Bibliotheken / Libraries ==
== 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.&nbsp;B. [[AVRDUDE]]) findet man [http://www.nongnu.org/avr-libc/user-manual/index.html hier].
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.&nbsp;B. [[AVRDUDE]]) findet man [http://www.nongnu.org/avr-libc/user-manual/index.html hier].


Auch die [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] enthält nützlichen Code z.&nbsp;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).
Auch die [http://www.procyonengineering.com/embedded/avr/avrlib/ Procyon AVRlib] enthält nützlichen Code z.&nbsp;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).
Zeile 73: Zeile 247:
== Tipps & Tricks ==
== Tipps & Tricks ==


Eine (hoffentlich wachsende) Liste mit einigen Hinweisen:
Eine Liste mit einigen Hinweisen:
 
* 07.10.11 → es kann Probleme mit der aktuellen Eclipse-Version (Indigo) und WinAVR geben. Falls ihr Indigo installiert habt und Eclipse die Definitionen wie z.B. DDRA nicht kennt, jedoch kompillieren kann, dann müsst ihr auf die Version Helios SR2 wechseln. Danach läuft alles wie gehabt!


* 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.&nbsp;B. [http://cdk4avr.sourceforge.net/ cdk4avr]).
* 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.&nbsp;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.
* 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.
* Sicherstellen, dass der MCU-Parameter (zum Compiler/Linker, meist im Makefile defniert) mit dem Zielprozessor übereinstimmt.
Zeile 83: Zeile 259:
* [[AVR-GCC-Tutorial]] in diesem Wiki lesen.
* [[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.
* 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.
* 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.&nbsp;B. im jeweils aktuellen WinAVR-Packet).
* 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.&nbsp;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(deprecated.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.&nbsp;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.
* inp(), outp(), sbi() und cbi() werden in der aktuellen Bibliotheksversion nicht offiziell unterstützt (man muss eine spezielle Header-Datei einbinden(deprecated.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.&nbsp;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  
* 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  
::<pre>avr-nm --size-sort --print-size -r -td <your_ELF_file></pre>
::<pre>avr-nm --size-sort --print-size -r -td <your_ELF_file></pre>
:aufgerufen. Alle Symbole mit einem "T" (globale Funktionen), "t" (lokale Funktionen) und letztlich auch mit einem "D" oder "d" (globale bzw. lokale Daten mit Initialisierungswerten 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 . (vgl. [http://www.mikrocontroller.net/topic/59960#467920 Forenbeitrag] von Jörg Wunsch)
:aufgerufen und gibt eine vierspaltige Liste aus: Die erste Spalte ist die Adresse, die zweite die benötigte Größe, die dritte der Typ und die vierte der Name des Symbols. Alle Symbole vom Typ "T" (globale Funktionen), "t" (lokale Funktionen) und letztlich auch die mit einem "D" oder "d" (globale bzw. lokale Daten mit Initialisierungswerten im ROM) betreffen das FLASH-ROM. Typen "B" und "b" brauchen ausschließlich RAM (werden beim Start mit 0 initialisiert). (vgl. [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.


* 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.
== Fußnoten ==
<references/>


== Siehe auch ==
== Siehe auch ==
Zeile 102: Zeile 281:
* [[GCC: unbenutzte Funktionen entfernen]]
* [[GCC: unbenutzte Funktionen entfernen]]
* [http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna AVR-GCC Interna]
* [http://www.roboternetz.de/wissen/index.php/Avr-gcc/Interna AVR-GCC Interna]
* [https://www.mikrocontroller.net/topic/479027#5934443 Forumsbeitrag]: RAM Verbrauch auch von lokalen variablen ermitteln


== Weblinks ==
== Weblinks ==

Aktuelle Version vom 9. August 2019, 16:18 Uhr

avr-gcc ist ein freier C-Cross-Compiler für AVR-Mikrocontroller.

avr-gcc kann von der Leistungsfähigkeit kommerzieller Compiler gut mithalten. Sogar C++-Programme sind möglich; in der aktuellen Fassung wird C++ jedoch nur eingeschränkt unterstützt (Stand 3/2012).

Bestandteile

Die Toolchain (Werkzeugsammlung) besteht aus mehreren Kommandozeilen-Programmen, die sich auf einfache Weise in einen Editor oder eine Entwicklungsumgebung einbinden lassen. Weit verbreitet ist die Verwendung von make zur Steuerung, siehe AVR-GCC-Tutorial: Exkurs Makefiles.

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

Atmel bietet die Atmel AVR Toolchain in verschiedenen Versionen zum Herunterladen an.

Wenn keine aktuelle avr-gcc-Version als Paket (Paketname ist, zumindest bei Debian, gcc-avr) für die verwendete Distribution zur Verfügung steht, dann können sich Unix/Linux-Nutzer den Sourcecode herunterladen und selbst kompilieren, dazu gibt es Schritt-für-Schritt-Anleitungen[1][2].

Das FemtoOS-Paket beinhaltet Scripte zum automatischen Herunterladen und Bauen einer avr-gcc Version 4.3.3.

Empfehlenswert ist auch CDK4AVR, das die entsprechenden Tools als einfach installierbare Linux-Pakete bereitstellt. Leider ist das Projekt schon etwas älter, im Forum findet sich ein Beitrag, aktuellere Sourcen mit den entsprechenden Patches zu versehen und zu kompilieren. Patches zu den Binutils und GCC-Sourcen sind unumgänglich, da die offiziellen Sourcen aufgrund des Umfangs an Prozessortargets den aktuellsten Entwicklungen hinterherhinken und damit bereits bekannte Fehler eventuell noch nicht behoben sind. Weitere Tipps zur AVR-Programmierung unter Linux stehen im Artikel AVR und Linux.

Mac OS X

Die beste fertige Toolchain ist das Crosspack. Dieses 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 Apple Developer Tools installieren.

Teile der Toolchain (AVR-Libc und avrdude) kann folgendermaßen installieren:

Mit MacPorts

Wenn man MacPorts benutzt kann man folgendes in das Terminal eingeben, um den Toolchain zu installieren:

sudo port install avr-libc

Das Programmiertool avrdude bekommt man genauso:

sudo port install avrdude

Mit Homebrew

Mit dem neueren Tool Homebrew funktioniert das folgendermaßen:

avrdude kann sofort installiert werden:

brew install avrdude

Für den restlichen Toolchain muss man erst ein 'Tap' hinzufügen:

brew tap osx-cross/avr

und kann dann den eigentlichen Toolchain installieren:

brew install avr-libc

Weblinks:

Windows

Man kann sich auch für Windows den GCC selbst bauen oder man sucht von anderen erstellte Binaries.

Atmel bietet die Atmel AVR Toolchain in verschiedenen Versionen zum Herunterladen an. Allerdings ohne "make".

Der alte Klassiker WinAVR wird seit 2010 nicht mehr gepflegt und funktioniert ab Windows 8 nur noch eingeschränkt.

Die Firma SysProgs bietet aktuelle Versionen der GNU Toolchain einschließlich "make" für viele Systemarchitekturen zum Download an.

Selbst bauen

Zuerst sei einmal die offizielle (englische) Anleitung genannt: Building and Installing avr-gcc

Das hier ist die etwas ausführlichere Beschreibung, die mir Johann L. gegeben hat, damit ich meinen Compiler erstellen konnte. Der Post dazu findet sich hier.

Zuerst einmal braucht man am besten ein Linux, zum Beispiel ein aktuelles Ubuntu. dort müssen diverse Programme wie gcc, autoconf, subversion usw. installiert sein. Wenn etwas fehlt meckert configure, das einfach aufmerksam lesen und dann die Programme nachinstallieren. Danach erneut configure aufrufen. Um die Toolchain für Windows zu bauen brauchen wir noch mingw32 (aktueller Name in den meisten Paketquellen: mingw32-w64-gcc oder gcc-w64-mingw32). Eventuell findet sich das in den Paketquellen eurer Distribution, sonst kann ich auf diese Seite verweisen.

Vorbereitungen

Wie schon gesagt brauchen wir ein Linux, zum Beispiel in einer VM. Ein minimales Linux-Hintergrundwissen wären auch gut, aber es geht notfalls (Google & co. sind die Freunde) auch ohne. Achtung: Auf diesem Linux darf kein avr-gcc und keine avr-libc vorhanden sein! Dazu brauchen wir die folgende Software:

  • GNU Binutils: Download, am besten die neueste Version (runter scrollen, aktuell ist 2.27)
  • GCC Sourcen: Download, diese sollten aus dem svn kommen (svn co svn://gcc.gnu.org/svn/gcc/branches/branchname gcc ,mit branchname gcc-version-branch, aktuell ist gcc-6-branch) oder aus dem aktuellen trunk (svn co svn://gcc.gnu.org/svn/gcc/trunk).
  • Die AVR-libc: Download. Achtung: Ab gcc-Version 5 muss mindestens eine avr-libc-Version >= 2.0.0 verwendet werden. Ältere GCCs brauchen natürlich auch eine avr-libc vor dieser Version.

Alles herunterladen und entpacken.

Zu den Downloads kommen dann noch 2 Umgebungsvariablen:

$ PREFIX=$HOME/local/avr
$ export PREFIX
$ PATH=$PATH:$PREFIX/bin
$ export PATH

Damit legt ihr das Installationsverzeichnis fest und fügt auch gleich das Verzeichnis für die ausführbaren Dateien zum Pfad hinzu.

Im Folgenden gehe ich von diesem Ordner-Layout aus:

$HOME
|
+ BuildToolchain
   |
   + Downloads
   |   |
   |   + binutils
   |   + gcc
   |   + avr-libc
   |
   + buildLinux
   |   |
   |   + binutils
   |   + gcc
   |   + avr-libc
   |
   + buildWindows
      |
      + binutils
      + gcc
Erstellen der Binutils

Wechselt in das Verzeichnis BuildToolchain/buildLinux/binutils. Von dort aus werden wir die binutils konfigurieren und erstellen.

Achtung: man darf weder GCC noch die Binutils in einem Verzeichnis innerhalb des Quellordners der Downloads konfigurieren, sonst kommen wirre Fehler. Wer sich an die Anleitung hält kann diesen Fehler (fast) nicht machen.

Also, wir sind soweit. Jetzt geht es ans Konfigurieren der binutils und danach ans kompilieren, aber das ist ganz leicht:

$ ../../Downloads/binutils/configure --prefix=$PREFIX --target=avr --disable-nls

Wenn configure fehlende Programme meldet: nachinstallieren und erneut versuchen.

$ make
$ make install

Damit sind die binutils für Linux fertig. Ihr könnt nachkontrollieren, ob die binutils da sind: Im Ordner $PREFIX/bin sollten sich die Dateien befinden, darunter avr-objcopy, avr-as, avr-size, etc.

Erstellen vom GCC

Als erstes muss sich der GCC noch ein paar zusätzliche Dateien herunterladen, das geschieht automatisch mit dem Befehl (ausgeführt in BuildToolchain/Downloads/gcc):

./contrib/download_prerequisites

Wechselt ins Verzeichnis BuildToolchain/buildLinux/gcc Dort führt ihr das Folgende aus:

$ ../../Downloads/gcc/configure --prefix=$PREFIX --target=avr \
    --enable-languages=c,c++,lto --disable-nls --disable-libssp --with-dwarf2
$ make
$ make install
Erstellen der avr-libc

Als erstes muss die avr-libs zum konfigurieren bereit gemacht werden: Im Verzeichnis BuildToolchain/Downloads/avr-libc die Datei bootstrap ausführen

./bootstrap

Danach wechselt ihr ins Verzeichnis BuildToolchain/buildLinux/avr-libc Dort führt ihr das Folgende aus:

$ ../../Downloads/avr-libc/configure --prefix=$PREFIX --build=`./config.guess` --host=avr
$ make
$ make install
Testen unter Linux

So, jetzt seit ihr schon bei der Hälfte: Der Compiler läuft schon unter Linux! Das testet ihr am besten schon mit ein paar einfachen LED-blink-Programmen, damit auch sichergestellt ist, dass bis hierhin alles geklappt hat. Das einfachste und wichtigste Kommando dürfte sein

$ avr-gcc --version

Dort sollte die Versionsnummer der GCC stehen. Wenn eine ältere Nummer dasteht, hab ihr entweder einen alten Download bemüht, oder eine andere Version vom avr-gcc war noch installiert. Wenn der Fehler kommt, dass das Programm nicht gefunden werden kann, dann befindet sich avr-gcc nicht im PATH, das bedeutet ihr habt die Umgebungsvariablen nicht richtig gesetzt (siehe oben).

Bau für Windows

Ihr müsst keine neuen Dateien runter laden, lediglich die Programme nochmal etwas anders konfigurieren. Die Schritte davor müssen jedoch ausgeführt werden!

Wechselt ins Verzeichnis BuildToolchain/buildWindows/binutils und führt das Folgende aus

$ ../../Download/binutils/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
    --host=plattform-w64-mingw32 --build=plattform-linux-gnu
$ make
$ make install

Wobei plattform euer Ziel-System ist, also entweder i686 oder x86_64, je nach dem, was ihr für ein mingw installiert habt und ob ihr den Compiler für 32bit (i686) oder 64bit (x86_64) baut.

Wechselt ins Verzeichnis BuildToolchain/buildWindows/gcc und führt das Folgende aus

$ ../../Downloads/gcc/configure --prefix=$HOME/local/avr4win --target=avr --disable-nls \
    --host=plattform-w64-mingw32 --build=plattform-linux-gnu --enable-languages=c,c++,lto --with-gnu-as \
    --with-gnu-ld --disable-shared --with-dwarf2
$ make
$ make install

Wechselt ins Verzeichnis BuildToolchain/buildLinux/avr-libc und führt den folgenden Befehl aus:

$ make install prefix=$HOME/local/avr4win

Eigentlich ist der Compiler auch "schon" fertig. Aber in den Binaries sind noch die gesamten Symbole enthalten, was die .exe-Dateien aufbläht. Um diese los zu werden, kann man einfach noch diesen Befehl ausführen:

$ find . -name '*.exe' -exec plattform-w64-mingw32-strip {} ';'

Damit sollten ihr im Ordner $HOME/local/avr4win die gesamte Toolchain haben. Diesen Ordner müsst ihr nur noch auf euren Windows-PC kopieren. Für das klassische WinAVR fehlt noch Programmers Notepad, sowie die Utility-Programme, vor allem avrdude und make. Diese kann man entweder seperat downloaden oder aus einer WinAVR-Installation kopieren. Die Versionen davon spielen keine Rolle.

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
  • SiSy-AVR: ein CASE-Tool mit WinAVR-Unterstützung, das eine Entwicklungsumgebung bereitstellt.

Plattformunabhängig:

Linux:

  • KontrollerLab ist eine freie Entwicklungsumgebung für AVR momentan aber noch im Beta-stadium.

Bibliotheken / Libraries

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

Auch die 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 avrfreaks.net (Anmeldung erforderlich (kostenlos)).

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

Tipps & Tricks

Eine Liste mit einigen Hinweisen:

  • 07.10.11 → es kann Probleme mit der aktuellen Eclipse-Version (Indigo) und WinAVR geben. Falls ihr Indigo installiert habt und Eclipse die Definitionen wie z.B. DDRA nicht kennt, jedoch kompillieren kann, dann müsst ihr auf die Version Helios SR2 wechseln. Danach läuft alles wie gehabt!
  • 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. cdk4avr).
  • Bei Problemen zuerst in die 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.
  • 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(deprecated.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
avr-nm --size-sort --print-size -r -td <your_ELF_file>
aufgerufen und gibt eine vierspaltige Liste aus: Die erste Spalte ist die Adresse, die zweite die benötigte Größe, die dritte der Typ und die vierte der Name des Symbols. Alle Symbole vom Typ "T" (globale Funktionen), "t" (lokale Funktionen) und letztlich auch die mit einem "D" oder "d" (globale bzw. lokale Daten mit Initialisierungswerten im ROM) betreffen das FLASH-ROM. Typen "B" und "b" brauchen ausschließlich RAM (werden beim Start mit 0 initialisiert). (vgl. 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.

Fußnoten

Siehe auch

Weblinks