'''avr-gcc''' ist ein freier C-[[Compiler]], mit dem C-Programme zu ausführbaren Programmen übersetzen werden können, die auf [[Microcontroller]]n der [[AVR]]-Familie lauffähig sind.

An Sprachen versteht avr-gcc sowohl C als auch [[#C%2b%2b|C++]].

Neben Standard-C bzw. ANSI-C versteht avr-gcc auch GNU-C, das etwas mehr Möglichkeiten und kleinere Spracherweiterungen bietet.

 

avr-gcc kann auch dazu verwendet werden, um C/C++ Programme nach Assembler zu übersetzen oder um Bibliotheken zu erstellen, die später in unterschiedlichen Projekten verwendet werden können.

 

Wie bei allen aus der UNIX-Welt kommenden Programmen ist das Kommando-Interface von avr-gcc die Shell bzw. die Kommandozeile, über die Optionen, Parameter, Einstellungen und die Namen der zu übersetzenden Dateien angegeben werden.  

Dieser Artikel bespricht avr-gcc Version 3.x. Er ist kein C-Tutorial und kein AVR-Handbuch – das würde den Umfang des Artikels bei weitem sprengen.  

Der Artikel ist ein Handbuch zu avr-gcc. Er bespricht zum Beispiel, wie avr-gcc angenwendet wird und Besonderheiten von avr-gcc-C, die nicht zum Sprachumfang von C gehören.

Dazu zählen die Definition von [[#Interrupts|Interrupt]] Service Routinen ([[ISR|ISRs]])  

befindet sich das ausführlichere Beispiel "[[Hallo Welt für AVR (LED blinken)]]",

das nur eine [[Diode#Lumineszenzdiode|LED]] blinkt und zeigt,  

wie ein kleines Projekt mit avr-gcc compiliert werden kann.

 

Es gibt ein [[C-Tutorial]], das jedoch noch unvollständig und teilweise feherhaft ist (Stand 02/2006). Darüber hinaus gibt es ein [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial C-Tutorial bei www.mikrocontroller.net].

Die Benutzer-Schnittstelle von avr-gcc ist – wie für alle Programme, die aus der UNIX-Welt kommen – die Kommandozeile einer Shell, Console bzw. Eingabeaufforderung.  

Im einfachsten Fall sieht ein Aufruf von avr-gcc also so aus:

Was bedeutet: das Programm avr-gcc wurde vom Betriebssystem gefunden und konnte/durfte gestartet werden. Dann gibt avr-gcc eine Fehlermeldung aus und beendet die Ausführung, weil er keine Eingabedatei(en) bekommen hat – was ja auch stimmt. Soweit ist also alles in Butter.

Um eine C-Datei <tt>foo.c</tt> mir avr-gcc optimiert zu einem lauffähigen elf-Programm <tt>foo.elf</tt> für einen [[ATmega32]] zu compileren, würde man angeben

> avr-gcc -Os -mmcu=atmega32 foo.c -o foo.elf

Hat man seine Quellen auf zwei oder mehre Dateien verteilt, geht es analog:

> avr-gcc -Os -mmcu=atmega32 foo.c foo2.c -o foo.elf

> avr-gcc -Os -c -mmcu=atmega32 foo.c -o foo.o

Die ausführbare Gesamtdatei <tt>foo_all.elf</tt> erhält man dann, indem alle Objekte zusammenlinkt:

> avr-gcc -mmcu=atmega32 foo.o foo2.o foo3.o -o foo_all.elf

Um die ausführbare Datei in das oft verwendete Intex-HEX-Format umzuwandeln (einmal fürs Programm, einmal für ein Abbild des [[EEPROM]]s) gibt man an:

> avr-objcopy -O ihex -j .text -j .data                        foo_all.elf  foo_all.hex

> avr-objcopy -O ihex -j .eeprom --change-section-lma .eeprom=1 foo_all.elf  foo_all_eeprom.hex

[[GCC]] war immer Kommandozeilen-orientiert und wird es auch immer bleiben, denn das hat gute Gründe:

* die Plattformabhängigkeit wird auf ein Minimum reduziert

* es gibt die Möglichkeit, avr-gcc per Skript oder [[make]] zu starten

* avr-gcc kann durchaus in eine Umgebung integriert werden: in einen Editor oder in eine GUI wie neuere Versionen von AVR-Studio erfolgreich beweisen, etc. Der avr-gcc-Aufruf kann sogar von einem Server-Socket oder einer Web-Application heraus erfolgen, welche ein C-Programm empfängt, es von avr-gcc übersetzen lässt, und das Resultat zurückschickt oder sonst was damit anstellt.

* Lizenzgründe: eine Umgebung, die avr-gcc integriert, kann durchaus proprietär oder nicht quelloffen sein und muss nicht der [[Freie Software|GPL]] unterliegen. Wieder ist AVR-Studio ein Beispiel.

= Unterstützte AVR-Derivate=

:→ ''[http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html GCC Manual: AVR Options]

> avr-gcc --target-help

bzw. ab Version 4.7 mit

> avr-gcc --help=target

Siehe auch "AVR Options" in der GCC [[#Dokumentation|Dokumentation]].

Die Codegenerierung bei avr-gcc wird über Kommandozeilen-Optionen gesteuert. Diese legen fest, für welchen Controller Code zu erzeugen ist, wie stark optimiert wird, ob Debug-Informationen erzeugt werden, etc. Die Optionen teilen sich in zwei Gruppen: Optionen, die für alle GCC-Ports verfürgbar sind und maschinenspezifische Optionen, die nur für AVR verfügbar sind.

; <tt>--target-help<br/>--help=target</tt>: Anzeige der wichtigsten maschinenspezifischen Optionen und der unterstützten AVR-Derivate

; <tt>-O0</tt>: keine Optimierung - sinnvoll zum debuggen

; <tt>-Os</tt>: optimiert für Code-Größe – meist beste Wahl für µCs

; <tt>-c</tt>: (pre)compilert und assembliert nur bis zum Objekt (<tt>*.o</tt>), kein Link-Lauf

; <tt>-S</tt>: (pre)compilert nur und erzeugt Assembler-Ausgabe (<tt>*.s</tt>)

; <tt>-E</tt>: nur Precompilat (<tt>*.i</tt> bzw. <tt>*.ii</tt>) erzeugen, kein Compilieren, kein Assemblieren, kein Linken

; <tt>-D<name></tt>: Definiert Makro <tt><name></tt>

; <tt>-save-temps</tt>: Temporäre Dateien (<tt>*.i</tt>, <tt>*.s</tt>) werden nicht gelöscht.

:;<tt>-Wl,--section-start=<section>=<address></tt>: Linker legt die [[avr-gcc/Interna#Sections|Section]] <tt><section></tt> ab Adresse <tt><address></tt>, z.B: <tt>.eeprom=0x810001</tt>

; <tt>-std=gnu99</tt>: Sagt dem Compiler, dass er C99 mit GNU-C Erweiterungen akzeptieren soll.  Das ist zum Beispiel der Fall, wenn man Embedded-C Code mit <tt>__flash</tt> verwenden will.

; <tt>-std=c89<br/>-ansi</tt>: bricht mit einer Fehlermeldung ab, wenn kein ANSI-C (ISO C89) verwendet wurde

; <tt>-std=c99</tt>: C99 mit einigen Erweiterungen, die nicht dem C99-Standard widersprechen

; <tt>-std=c99 -pedantic</tt>: Bricht mit einer Fehlermeldung ab, wenn kein ISO C99 verwendet wird

;-mmcu=xxx: Festlegen des Targets (Zielsystem/Controller), für das Code generiert werden soll. Je nach Target muss avr-gcc unterschiedliche Instruktionen verwenden und andere Startup-Dateien (<tt>crtxxx.o</tt>) einbinden. avr-gcc setzt spezielle Defines, um auch in der Quelle zwischen den Targets unterscheiden zu können, falls das notwendig sein sollte:  

:{| border="0" cellpadding="0" cellspacing="0"

<pre>

#ifdef __AVR_AT90S2313__

/* Code fuer AT90S2313 */

#elif defined (__AVR_ATmega8__) || defined (__AVR_ATmega32__)

/* Code fuer Mega8 und Mega32 */  

#else

#error Das ist noch nicht implementiert für diesen Controller!

#endif

</pre>

: Zwar gibt es für alle AVR-Derivate die <tt>avr/io.h</tt>, aber die AVR-Familien unterscheiden sich in ihrer Hardware; z.B. darin, wie I/O-Register heissen oder wie Hardware zu initialisieren ist. Diese Abhängigkeit kann man in unterschiedlichen Codestücken aufteilen und wie oben gezeigt bedingt übersetzen. Dadurch hat man Funktionalitäten wie <tt>uart_init</tt> auf unterschiedlichen Controllern und wahrt den Überblick, weil nicht für jede Controller-Familie eine extra Datei notwendig ist.

: Built-in Makros wie <tt>__AVR_ATmega8__</tt> und <tt>__AVR_ARCH__</tt> sind ab Version 4.7 im Kapitel "AVR Options" in der GCC [[#Dokumentation|Dokumentation]] erklärt, siehe z.B. [http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html "AVR Built-in Macros"].

; -mint8: Datentyp <tt>int</tt> ist nur 8 Bit breit anstatt 16 Bit. Datentypen mit 64 Bit sind nicht verfügbar. 8-Bit <tt>int</tt> ist nicht C-Standard konform und wird nicht von der AVR Libc unterstützt (ausser in <tt>stdint.h</tt>).

=C++=

:''"C++ is a complex language and an evolving one, and its standard definition (the ISO C++ standard) was only recently completed. As a result, your C++ compiler may occasionally surprise you, even when its behavior is correct."''

Zudem sollte der Einsatz von C++ aus Effizienzgründen sehr kritisch betrachtet werden:

:''"When programming C++ in space- and runtime-sensitive environments like microcontrollers, extra care should be taken to avoid unwanted side effects of the C++ calling conventions like implied copy constructors that could be called upon function invocation etc. These things could easily add up into a considerable amount of time and program memory wasted. Thus, casual inspection of the generated assembler code (using the <tt>-S</tt> compiler option) seems to be warranted."''

Weiterhin unterliegt der Einsatz von C++ je nach Compiler/Lib-Version bestimmten Einschränkungen:

*Einer kompletten C++ Implementierung fehlt die Unterstützung durch die <tt>libstdc++</tt>, dadurch fehlen Standardfunktionen, -Klassen und -Templates

* Die Operatoren <tt>new</tt> und <tt>delete</tt> sind nicht implementiert, ihre Verwendung führt zu unauflösbaren externen Referenzen (Linker-Fehler)

*Nicht alle Header sind C++-sicher und müssen in <tt>extern "C" {...}</tt> eingeschlossen werden.

*Exceptions werden nicht unterstützt und müssen via <tt>-fno-exceptions</tt> abgeschaltet werden, oder der Linker beschwert sich über eine unauflösbare externe Referenz zu <tt>__gxx_personality_sj0</tt>.

Als Treiber verwendet man wie immer avr-gcc. Standard-Endungen für C++ sind <tt>.c++</tt> und <tt>.cpp</tt>. Bei anderen Endungen teilt man mit <tt>-x c++</tt> mit, daß es sich um C++ Dateien handelt, oder ruft <tt>avr-c++</tt> direkt auf.

Globale Konstruktoren werden in [[avr-gcc/Interna#Sections|Section]] <tt>.init6</tt> ausgeführt, die Destruktoren in <tt>.fini6</tt>.

Dieser Abschnitt enthält Code-Schnippsel für avr-gcc. Es werden Besonderheiten besprochen, die für avr-gcc zu beachten sind.  

Dieser Abschnitt ist ''kein'' [[C-Tutorial|Tutorial zur C-Programmierung]] und ''keine'' Einführung in die Programmiersprache C im allgemeinen. Dafür sei auf einschlägige Tutorials/Bücher verwiesen.

Für den Zugriff auf die SFRs gibt es Defines über den Include

#include <avr/io.h>

Abhängig vom eingestellten Controller werden dann Defines eingebunden, über die auf SFRs wie auf normale Variablen zugegriffen werden kann. Die Namen der Defines sind i.d.R. die gleichen wie im AVR-Manual, also z.b. <tt>SREG</tt> für das Prozessorstatus-Register SREG:

#include <avr/io.h>

...

   {{ccomment|SREG lesen}}

   {{ccomment|SREG schreiben}}

Das bedeutet in etwa: "Lies ein flüchtiges (<tt>volatile</tt>) Byte (<tt>unsigned char</tt>) von Adresse <tt>0x5f</tt>". Der Speicherinhalt von SFRs ist flüchtig, denn er kann sich ändern, ohne daß avr-gcc dies mitbekommt. Daher muss bei jedem C-Zugriff auf ein SFR dieses wirklich gelesen/geschrieben werden, was der Qualifier <tt>volatile</tt> sicherstellt. Ansonst geht der Compiler u.U. davon aus, daß der Inhalt bekannt ist und verwendet einen alten, in einem GPR befindlichen Wert.

:<tt> &lt;GCC_HOME&gt;/avr/include/avr/io****.h</tt>

Dieser Zugriff geht auch für 16-Bit Register wie <tt>TCNT1</tt> oder <tt>ADC</tt>, für die eine bestimmte Reihenfolge für den Zugriff auf Low- und High-Teil eingehalten werden muss: avr-gcc generiert die Zugriffe in der richtigen Reihenfolge.

Zu beachten ist, daß dieser Zugriff nicht atomar erfolgt. Das Lesen/Schreiben mehrbytiger Werte muss vom Compiler in mehrere Byte-Zugriffe zerlegt werden. Zwischen diesen Zugriffen kann ein [[Interrupt]] auftreten, wenn Interrupts aktiviert sind. Je nach Programm und welche Aufgaben eine [[ISR]] erledigt, kann dies zu Fehlfunktion führen. In dem Fall müssen diese Code-Stücke atomar gemacht werden, damit sie nicht durch einen [[IRQ]] unterbrochen werden können!

Auch das Lesen einzelner Port-Pins geht über das Maskieren von SFRs:

DDRB &= ~(1 << PB2);    // PortB.2 als INPUT

if (PINB & (1 << PB2))

   // PortB.2 ist HIGH

 

if (!(PINB & (1 << PB2)))

   // PortB.2 ist LOW

: → ''[http://nongnu.org/avr-libc/user-manual/group__avr__interrupts.html AVR-Libc: Dokumentation zu <tt><avr/interrupt.h></tt>].

 

Um zu kennzeichnen, daß es sich bei einer Funktion um eine Interrupt Sevice Routine (ISR) handelt, gibt es spezielle Attribute. Diese brauchen nicht explizit hingeschrieben zu werden, ebensowenig wie die genaue Nummer des Interrupt Requests (IRQ). Dafür gibt es Includes aus der AVR Libc und die folgenden Makros.

 

  ISR (TIMER1_COMPA_vect)

  {

ISR (TIMER0_OVF_vect, ISR_NOBLOCK)

    {{ccomment|ISR-Code}}

 

Mit Ausführung einer ISR deaktiviert die AVR-Hardware die Interrupts, so daß die ISR nicht durch andere Interrupt-Anforderungen unterbrochen wird. Beim Verlassen der ISR werden Interrupts wieder automatisch durch die AVR-Hardware aktiviert. Tritt während der ISR ein IRQ auf, wird diese erst nach Beenden des ISR-Codes ausgeführt. Der Interrupt geht also nicht verloren.  Dies gilt allerding nicht für Level-getriggerte IRQs wie für manche externen Interrupts oder TWI-Interrupts.

Zwischen zwei ISRs wird zusätzlich mindestens ein Befehl des normalen Programm-Codes abgearbeitet.

Nachschlagen kann man die ISR-Namen im Device-spezifischen Header, die im Installationsverzeichnis liegen:

#include <avr/io.h>

#include <avr/interrupt.h>

    ...

    {{ccomment|enable OutputCompareA Interrupt für Timer1}}

    TIMSK |= (1 << OCIE1A);

    {{ccomment|disable OutputCompareA Interrupt für Timer1}}

    TIMSK &= ~(1 << OCIE1A);

    {{ccomment|Interrupts aktivieren}}

    sei();

    {{ccomment|Interrupts abschalten}}

    cli();

Sperrt man eine Code-Sequenz durch Einschachteln in ein <tt>cli</tt>/<tt>sei</tt> Paar (man macht das Codestück "atomar", also ununterbrechbar), gehen währenddessen keine Interrupt-Anforderungen verloren. Die entsprechenden IRQ-Flags bleiben gesetzt, und nach dem <tt>sei</tt> werden die IRQs in der Reihenfolge ihrer Prioritäten abgearbeitet. Ausnahme ist, wenn in einem atomaren Block der selbe IRQ mehrfach auftritt. Der ISR-Code wird dann trotzdem nur einmal ausgeführt.

Für nicht implementierte Interrupts macht avr-gcc in die Vektortabelle einen Eintrag,

&#150; allerdings ohne die Hardware zurückzusetzen wie bei einem echten Reset.

#include <avr/interrupt.h>

ISR (__vector_default)

sondern weiter zu <tt>__vector_default</tt>, welches durch <tt>ISR()</tt> den üblichen ISR-Prolog/Epilog bekommt.

So kann man z.B. eine Meldung ausgeben, eine Warnlampe blinken, in einer Endlosschleife landen, oder über den [[Watchdog]] einen richtigen Hardware-Reset auslösen, siehe auch Abschnitt "[[#Reset auslösen|Reset auslösen]]".

Dabei ist darauf zu achten, daß die ISR mit <tt>reti</tt> (return from interrupt)

zurückkehrt und evtl. verwendete Register und den Status (<tt>SREG</tt>) sichert.

 

ISR (TIMER0_OVF_vect, ISR_NAKED)

{

    {{ccomment|Port B.6 &#61; 0}}

    __asm__ __volatile (

      "cbi %0, %1" "\n\t"

      "reti"

          :  

          : "M" (_SFR_IO_ADDR (PORTB)), "i" (6)

    );

}

 

   c6 98       cbi  0x18, 6

   18 95       reti

 

dann werden die Strings im SRAM abgelegt. Im Startup-Code werden die Strings vom Flash ins SRAM kopiert und belegen daher sowohl Platz im SRAM als auch im Flash. Wird ein String nicht verändert, braucht er nicht ins SRAM kopiert zu werden. Das spart Platz im knapp bemessenen SRAM. Allerdings muss anders auf den String zugegriffen werden, denn wegen der Harvard-Architektur des AVR-Kerns kann avr-gcc anhand der Adresse nicht unterscheiden, ob diese ins SRAM, ins Flash oder ins EEPROM zeigt.

  const char str3[] PROGMEM = "Hallo Welt!";

  size_t strlen_P (const char *str)

     size_t len = 0;

  void foo (void)

     size_t len;

     len = strlen_P (PSTR ("String im Flash"));

  const char str4[] EEMEM = "Hallo Welt!";

  size_t strlen_EE (const char *str)

     size_t len = 0;

 

Falls ein Reset per Software ausgelöst werden soll, dann geht das am besten über den [[Watchdog]].

Einfach nur an den Reset-Punkt an Adresse&nbsp;0 zu springen

Durch den Watchdog kann man ein 'richtiges' RESET-Signal erzeugen lassen, so daß die AVR-Hardware genau so initialisiert ist, wie nach einem externen RESET. So kann man z.B. via [[UART]] ein RESET-Kommando schicken. Allerdings lässt sich der Watchdog nur minimal auf 15ms einstellen:

  #include <avr/wdt.h>

#include <avr/interrupt.h>

... 

    cli();                    {{ccomment|Interrupts global abschalten}}

    while (1);                {{ccomment|warten, bis er zubeisst...}}

Welches Ereignis einen RESET ausgelöst hat, kann man im Register '''MCUCSR''' (''MCU Control and Status Register'') erfahren. Es gibt 4 mögliche RESET-Quellen:

Soll der Inhalt von Variablen einen Reset überleben &ndash; eine Variable also nicht initialisiert werden &ndash; dann geht das so:

  {{ccomment| status informiert z.B. darüber, ob wir selber den Watchdog ausgelöst haben }}

uint8_t status __attribute__ ((__section__ (".noinit")));

int main (void)

    uint8_t mcucsr = MCUCSR;

    MCUCSR = 0;

    if (mcuscr & (1 << WDRF))

   

    if (mcuscr & (1 << PORF))

        status = 0;

Falls wirklich zu Adresse 0 gesprungen werden soll – was in einem Bootloader erforderlich sein kann – dann geschieht das mittels einer Funktion <tt>reset</tt> wie folgt:

  extern void reset (void) __attribute__((noreturn));

  reset();

<tt>reset</tt> wird bein Linken mittels <tt>-Wl,--defsym=reset=0</tt> auf&nbsp;0&nbsp;gesetzt.

Weitere Möglichkeit ist, im erzeugten Assembler&nbsp;<tt>0</tt> als Funktionsnamen zu verwenden:

extern void reset (void) __asm__("0") __attribute__((__noreturn__));

reset();

angegebenen Includes werden von avr-gcc in den  

Dem Compiler bekannt sind die Pfade

<GCC_HOME>/avr/include                          Standard              (stdio.h, ...)

<GCC_HOME>/avr/include/avr                      AVR-spezifisch        (avr/io.h, ...)

<GCC_HOME>/lib/gcc/avr/<GCC_VERSION>/include    Standard, compilerabh. (limits.h, ...)

 

In den Verzeichnissen stehen Standard-Includes, die benötigt werden, wenn man libc-Funktionen  

oder mathematische Funktionen etc. verwendet.  

  ctype.h                  Zeichen-Umwandlungs-Makros und ctype Makros

  errno.h                  Symbolische Namen für Fehlercodes

  stdint, inttypes.h       C99 definiert [u]intN_t wenn man genau N [un]signed

                           Bits braucht

  math.h                    Mathematische Funktionen: sin, cos, log, gamma, bessel, ...

  setjmp.h                  libc unterstützt setjmp() und longjmp(), um direkt in eine

                           andere (nicht-lokale) Funktion zu springen.  

  stdio.h                  Standard I/O-Funktionen (printf, fscanf, ...)

  stdlib.h                  Deklariert grundlegende ISO C Makros und Funktionen

                           sowie einige AVR-spezifische Erweiterungen

  string.h                  Stringoperationen auf NULL-terminierten Strings. (strlen, ...)

Dadurch werden genau die I/O-Header eingebunden, die zum AVR-Modell passen, also z.B. <tt>avr/iom8.h</tt> für [[ATmega8]] etc.  Verantwortlich für die Auswahl des richtigen Sub-Headers ist der Schalter '<tt>-mmcu=xxx</tt>'.

Obwohl diese Sub-Header nicht explizit angegeben werden müssen,  

Ihre Namen sind immer <tt>avr/io*.h</tt>.

* für ATmega: <tt>avr/iom*.h</tt>  

* für ATtiny: <tt>avr/iotn*.h</tt>

avr/interrupt.h      sei(), cli(), ISR(), ...

avr/io.h              RAMEND, ***_vect, SFRs: PORTB, DDRB, PINB, SREG, ...,

avr/pgmspace.h        Zugriff aufs Flash: Byte lesen, PROGMEM, pgm_read_***, ...