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

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 Hombrew

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 larsimmisch/homebrew-avr

und kann dann den eigentlichen Toolchain installieren:

brew install avr-libc

Weblinks:

Windows

Atmel bietet die Atmel AVR Toolchain 3.4.x for Windows zum herunterladen an.

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
  • 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