AVR-GCC

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

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