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

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. Es gibt einen Unterartikel, der [[avr-gcc/Interna|Interna von avr-gcc]] zusammenfasst.

Der Artikel ist ein Handbuch zu avr-gcc. Er bespricht zum Beispiel, wie man avr-gcc anwendet und Besonderheiten von avr-gcc-C,

die nicht zum Sprachumfang von C gehören.

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

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

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

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

* ein Compiler ist ein Compiler ist ein Compiler (und keine grafische Bedienschnittstelle)

; <tt>--target-help</tt>: Anzeige der wichtigsten maschinenspezifischen Optionen

; <tt>-O0</tt>: keine Optimierung

; <tt>-Os</tt>: optimiert für Code-Größe

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

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

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

; <tt>-pedantic</tt>: geht besonders pedantisch mit Code um

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

; <tt>-ffreestanding</tt>: Das erzeugte Programm läuft nicht in einer Umgebung wie einer Shell. Der Prototyp von <tt>main</tt> ist

;-mmcu=xxx: Festlegen des Targets (Zielsystem/Controller), für das Code generiert werden soll. Je nach Target muss avr-gcc unterschiedliche Instruktionen verwendet 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:  

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.

 

:{| {{Blauetabelle}}

|- bgcolor="#ccccff"

|[[Atmel Controller Mega8|atmega8]] ||<tt>__AVR_ATmega8__</tt>

|atmega8515 ||<tt>__AVR_ATmega8515__</tt>

|+ '''AVR enhanced, &gt; 8 kByte'''

|- bgcolor="#ccccff"

|[[Atmel Controller Mega16 und Mega32|atmega16]] ||<tt>__AVR_ATmega16__</tt>

|[[Atmel Controller Mega16 und Mega32|atmega32]] ||<tt>__AVR_ATmega32__</tt>

|atmega323 ||<tt>__AVR_ATmega323__</tt>

|[[ATMega64|atmega64]] ||<tt>__AVR_ATmega64__</tt>

|[[Atmel Controller Mega128|atmega128]] ||<tt>__AVR_ATmega128__</tt>

|at94k ||<tt>__AVR_AT94K__</tt>

 

----<!----------------------------------------------------------->

 

 

|+ '''AVR, nur Assembler'''

|- bgcolor="#ccccff"

 

; -mint8: Datentyp <tt>int</tt> ist nur 8 Bit breit, anstatt 16 Bit. Datentypen mit 32 Bit wie <tt>long</tt> sind nicht verfügbar

For den Zugriff auf die SFRs gibt es Defines über den Include

Abhängig vom eingestellten Controller werden denn 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:

Für einen Überblick über die eingebundenen Defines und kann ein Blick in den Controller-spezifischen Header hilfreich sein. Dieser befindet sich in

Dieser Zugriff geht auch für 16-Bit Register wie <tt>TCNT1</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.

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 und die folganeden Makros.

Bitte beachte auch die Hinweise zu den [[#Inkompatibilität|Inkompatibilität]]en von avr-gcc!

#include <avr/io.h>

#include <avr/signal.h>

SIGNAL (SIG_OUTPUT_COMPARE1A)

{

  /* ISR-Code */

}

  /* ISR-Code */

Dadurch wird die Funktion mit dem richtigen Prolog/Epilog erzeugt, und es wird ein Eintrag in die Interrupt-Vektortabelle gemacht &#150; bei obigem Beispiel also zwei Einträge.

Die Schreibweise des Signal-Names muss genau die sein wie im Header, das schliesst auch Leerzeichen ein! Nicht alle GCC-Versionen bringen Fehler/Warnung, wenn die Schreibweise nicht stimmt.

;<tt>SIGNAL</tt>: Mit Ausführung einer ISR deaktiviert die AVR-Hardware die Interrupts, sodaß die ISR nicht durch andere Interrupt-Anforderungen unterbrochen wird. Beim Verlassen der ISR werden Interrupts wieder 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. Zwischen zwei ISRs wird zusätzlich mindestens ein Befehl des normalen Programm-Codes abgearbeitet.

;<tt>INTERRUPT</tt>: Früh im ISR-Prolog werden mit <tt>sei</tt> die von der AVR-Hardware temporär deaktivierten Interrupts reaktiviert. Dadurch kann die ISR von einer IRQ unterbrochen werden. Das bietet die Möglichkeit, so etwas wie Interrupt-Priorisierung nachzubilden, was AVRs selbst nicht können. Weiterhin kann man schneller auf bestimmte Ereignisse reagieren. Tritt während der ISR ein anderer IRQ auf, der schnell bedient werden muss, kann sofort der dringende ISR-Code ausgeführt werden. Ansonsten (Verwendung von <tt>SIGNAL</tt>) würde der Code erst ausgeführt werden, nachdem die aktuelle ISR beendet ist.

 

 

#include <avr/io.h>

#include <avr/interrupt.h>

 

  ...

  // enable OutputCompareA Interrupt für Timer1

  TIMSK |= (1 << OCIE1A);

 

  // disable OutputCompareA Interrupt für Timer1

  TIMSK &= ~(1 << OCIE1A);

 

  // Interrupts aktivieren

  sei();

 

  // Interrupts abschalten

  cli();

SIGNAL (__vector_default)

sondern weiter zu <tt>__vector_default</tt>, welches durch <tt>SIGNAL</tt> oder

<tt>INTERRUPT</tt> den üblichen ISR-Prolog/Epilog bekommt.

dann definiert man eine nackte Funktion.

<pre>

#include <avr/io.h>

  /* Port B.6 = 0                                                        */

void __attribute__ ((naked))  

  const prog_char str3[] = "Hallo Welt!";

  unsigned int strlen_P (const prog_char *str)

     unsigned int len = 0;

  void foo()

     unsigned int len;

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

  const char str4[] __attribute__ ((section(".eeprom"))) = "Hallo Welt!";

  unsigned int strlen_EE (const char *str)

     unsigned int len = 0;

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

#include <avr/wdt.h>

#include <avr/interrupt.h>

...   

  cli();                    // Interrupts global abschalten

  wdt_enable (WDTO_15MS);    // Watchdog aufziehen auf 15ms

  while (1);                // warten, bis er zubeisst...

#include <avr/io.h>

unsigned char status __attribute__ ((section (".noinit")));

 

  MCUCSR = 0;

 

 

 

 

 

 

 

Mitunter ist es notwendig, Code unmittelbar nach dem Reset auszuführen, noch bevor man in <tt>main()</tt> mit der eigentlichen Programmausführung beginnt. Das kann zB. zur Bedienung eines [[Watchdog]]-Timers erforderlich sein.

 

Nach einen Reset und vor Aufruf von <tt>main</tt> werden Initialisierungen ausgeführt wie

* Vorbelegung globaler Datenobjekte: Daten ohne Initializer werden zu 0 initialisert ([[avr-gcc/Interna#Sections|Section]] <tt>.bss</tt>). Für Daten mit Initializer (Section <tt>.data</tt>) werden die Werte aus dem Flash ins SRAM kopiert.

 

void __attribute__ ((naked, section (".init3")))

code_init3 (void)

Der Code in den <tt>.init''n''</tt>-Sections wird sequenziell ausgeführt, daher darf in diese Sections nur der nackte Funktions-Code, ohne Prolog und ohne Epilog (also auch ohne <tt>ret</tt>-Instruktion!). Da disee nackten Funktionen kein <tt>ret</tt> haben, dürfen sie nicht explizit aufgerufen werden! Ihr Aufruf erfolgt implizit dadurch, daß ihr Code in einer <tt>init</tt>-Section steht.

 

* Zuweisungen wie <tt>i=0;</tt> ergeben vor <tt>.init3</tt> inkorrekten Code, da vor Ende von <tt>.init2</tt> Register R1 noch nicht mit 0 besetzt ist, avr-gcc aber davon ausgeht, daß es eben diesen Wert enthält.

* Lokale Variablen müssen in Registern liegen, denn vor Ende von <tt>.init2</tt> ist der Stackpointer noch nicht initialisiert. Zudem ist die Funktion <tt>naked</tt>, hat also insbesondere keinen Prolog, der den Framepointer (Y-Register) setzen könnte, falls er benötigt wird.

* Gegebenenfalls ist daher die Verwendung von [[Inline-Assembler in avr-gcc|inline-Assembler]] angezeigt oder die Implementierung in einem eigenen Assembler-Modul, das dazu gelinkt wird. Der erzeugte Code ist im List-File zu überprüfen.

;<tt>.init2</tt>: Initialisieren von R1 mit 0 und setzen des Stackpointers

;<tt>.init4</tt>: Kopieren der Daten vom Flash ins SRAM (<tt>.data</tt>) und löschen von <tt>.bss</tt>

;<tt>.init6</tt>: C++ Konstruktoren

;<tt>.init9</tt>: Sprung zu <tt>main</tt>

 

  inttypes.h               Definiert [u]intN_t wenn man genau N [un]signed Bits

                           braucht, ISO C99.

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

  stdlib.h                  Deklariert grundlegende ISO C-Makros und -Funktionen  

Dadurch werden z.B. genau die I/O-Header eingebunden, die zum AVR-Modell passen, also

*<tt>avr/iom8.h</tt> für [[ATmega8]],

*<tt>avr/io2313.h</tt> für [[AT90S2313]], etc.  

 

Verantwortlich dafür ist der Schalter '<tt>-mmcu=xxx</tt>'.

Obwohl diese Header nicht explizit angegeben werden müssen,  

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

avr/io.h              --> inttypes.h, io*.h

avr/io*.h            SFRs, SIG_****, SPM_PAGESIZE, RAMEND, XRAMEND, E2END, FLASHEND

avr/parity.h          [*] Parität

avr/pgmspace.h        Zugriff aufs Flash: Byte lesen, PROGMEM, prog_char, prog_uint8_t, ...

avr/signal.h          [**] Makros SIGNAL() und INTERRUPT(), ...

avr/sleep.h          Power-Safe

=Optimierungen, Tipps & Tricks=

 

 

 

:''"Unlike most other C compilers, GCC allows you to use -g with -O. The shortcuts taken by optimized code may occasionally produce surprising results: some variables you declared may not exist at all; flow of control may briefly move where you did not expect it; some statements may not be executed because they compute constant results or their values were already at hand; some statements may execute in different places because they were moved out of loops.''

 

 

 

 

 

Und für <tt>malloc</tt> und Konsorten sind dynamische Arrays und das Compiler-Builtin <tt>__builtin_alloca</tt> effizientere Alternativen, siehe auch im Abschnitt "[[avr-gcc#Dynamische Speicherallokierung|Dynamische Speicherallokierung]]".

 

 

Entsprechende Routinen, um auf Strings im Flash zuzugreifen, tragen die Suffix <tt>_P</tt>, wie z.B. <tt>strcmp_P</tt> mit dem Prototyp

 

  {{ccomment|String im SRAM mit String im Flash vergleichen}}

 

#include <avr/pgmspace.h>

{{ccomment|oder -1, falls text nicht gefunden wurde.}}

    {{ccomment|sizeof wird von gcc ausgewertet und ist wie eine Konstante,}}

 

const prog_char str_1[] = "Befehl 1";

const prog_char str_2[] = "Befehl für func2";

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

'''Beispiel: Umwandeln nach Dezimalstring'''