RN-Wissen.de - Benutzerbeiträge [de]

GCC

2006-03-20T11:21:28Z

Alexander.stohr:

GCC ist ein sehr leistungsfähiger [[Compiler]], und er kann als die wichtigste freie Software überhaupt bezeichnet werden. Immerhin sind das freie [[Betriebssystem]] <tt>Linux</tt> und viele andere Programme auch gcc und die Toolchains selbst mit gcc generiert.

Avr-gcc

2006-03-20T11:21:15Z

Alexander.stohr:

Die GNU Compiler Collection ([[GCC]]) unterstützt das Zielsystem (Target) [[Avr|AVR]] für die Sprachen C und C++.


=How to Read=

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

Der Artikel ist ein Handbuch zu <tt>avr-gcc</tt>. Er bespricht zum Beispiel, wie man <tt>avr-gcc</tt> anwendet und Besonderheiten von <tt>avr-gcc</tt>-C,
die nicht zum Sprachumfang von C gehören.
Dazu zählen die Definition von [[#Interrupts|Interrupt]] Service Routinen ([[ISR|ISRs]])
oder wie man Daten ins [[EEPROM]] legt.

Es wird also besprochen, ''wie'' eine ISR zu definieren ist, aber nicht,
''warum'' das gegebenenfalls notwendig oder nicht notwendig ist.
''Warum'' etwas gemacht wird, ist abhängig von der gestellten Aufgabe,
etwa ''"Initialisiere den [[UART]] zur Benutzung mit 9600 Baud"''.
Dafür enthält dieser Artikel zusammen mit dem AVR-Handbuch das Rüstzeug,
bietet aber keine Lösungen für konkrete Aufgaben.

In den [[:Kategorie:Quellcode C|C-Codebeispielen]]
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 <tt>avr-gcc</tt> compiliert werden kann.

Es gibt es ein allgemeines [[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].

=Benutzer-Schnittstelle=

Die Benutzer-Schnittstelle von GCC ist die Kommandozeile einer Shell, Console bzw. Eingabeaufforderung.

Im einfachsten Fall sieht ein Aufruf von <tt>avr-gcc</tt> also so aus:
> avr-gcc
Dabei das '<tt>></tt>' nicht mittippen, und ein ENTER am Ende der Zeile drücken.
Die Antwort bei korrekter Installation ist dann
avr-gcc: no input files
Was bedeutet: das Programm <tt>avr-gcc</tt> wurde vom Betriebssystem gefunden und konnte/durfte gestartet werden. Dann gibt <tt>avr-gcc</tt> 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.

GCC war immer Kommandozeilen-orientiert und wird es auch immer bleiben, denn das hat gute Gründe:
* ein Compiler ist ein Compiler ist ein Compiler (und keine grafische Bedienschnittstelle)
* die Plattformabhängigkeit wird auf ein Minimum reduziert
* es gibt die Möglichkeit, GCC per Skript oder [[make]] zu starten
* 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 GCC-Aufruf kann sogar von einem Server-Socket oder einer Web-Application heraus erfolgen, welche ein C-Programm empfängt, es von GCC übersetzen lässt, und das Resultat zurückschickt oder sonst was damit anstellt.
* Lizenzgründe: eine Umgebung, die GCC integriert, kann durchaus proprietär oder nicht quelloffen sein und muss nicht der [[Freie Software|GPL]] unterliegen. Wieder ist AVR-Studio ein Beispiel.

=Allgemeine Charakteristika von avr-gcc=

;Groß- und Kleinschreibung: C unterscheidet generell zwischen Groß- und Kleinschreibung, sowohl bei Variablen- und Funktionsnamen, bei Sprungmarken als auch bei Makros, und je nach Betriebssystem auch bei Pfad- und Dateinamen/Dateierweiterungen.

;Größe des Typs int: Der Standard-Typ <tt>int</tt> ist 16 Bit groß

;Größe von Pointern: Ein Pointer (Zeiger) ist 16 Bit groß

;Endianess: <tt>avr-gcc</tt> implementiert Datentypen als little-endian, d.h. bei Datentypen, die mehrere Bytes groß sind, wird das niederwertigste Byte an der niedrigsten Adresse gespeichert. Dies gilt auch für Adressen und deren Ablage auf dem [[Stack]] sowie die Ablage von Werten, die mehrere Register belegen.

;<tt>size_t</tt>: <tt>size_t</tt> ist <tt>unsigned</tt> und immer 16 Bit groß, unabhängig davon , ob mit <tt>-mint8</tt> übersetzt wird oder nicht.

==Binäre Konstanten==
Einige Versionen von <tt>avr-gcc</tt> ermöglichen die Verwendung binärer Konstanten für Ganzzahl-Werte:
<pre>unsigned char value = 0b00000010;</pre>
Davon sollte man absehen, denn zum einen hat man schnell eine 0 zu wenig oder zu viel getippselt, es ist kein Standard-C und man hat die leserlichere Alternative
<pre>unsigned char value = (1<<1);</pre>

==Registerverwendung==
;R0: ein temporäres Register, in dem man rumwutzen darf
;R1: enthält immer den Wert 0
;R1 R17, R28, R29: allgemeine Register, die durch einen Funktionsaufruf nicht verändert bzw wieder auf den ursprünglichen Wert restauriert werden
;R0, R18 R27, R30, R31: können durch Funktionsaufrufe verändert werden, ohne restauriert zu werden

;Framepointer: R28 R29 (Y-Reg) enthält den Framepointer, sofern benötigt
;Argument-Register: Die Register R8 bis R25 finden Verwendung zur Übergabe von Funktionsparametern. Für den Ort, an dem das Argument übergeben wird, gilt:
:* Die Große in Bytes wird zur nächsten geraden Zahl aufgerundet, falls die Argumentgröße ungerade ist.
:* Ist in den verbleibenden Übergaberegistern kein Platz mehr oder ist das Argument namenlos (varargs), wird es im Memory übergeben und die Adresse als implizites erstes Argument.
:* Der Registerort fängt mit 26 an.
:* Von dem Registerort wird die berechete Größe abgezogen und (falls Platz) das Argument in diesen Registern übergeben. Ist das erste Argument z.B. ein <tt>long</tt>, dann erfolgt die Übergabe in den Registern R22, R23, R24 und R25 (LSB zuerst). Danach wird die gerundete Größe des Arguments vom Registerort abgezogen, dieser also auf 22 gesetzt. Ist das nächste Argument ein <tt>char</tt>, wird dessen Größe auf 2 aufgerundet und vom Ort abgezogen. Dieses Argument wird also in R20 übergeben und der Ort auf 20 gesetzt, etc.
;Return-Register: Ein Return-Wert wird in den gleichen Registern zurückgegeben, die auch für ein gleichgrosses erstes Funktionsargument genommen würden. Liefert eine Funktion ein <tt>long</tt>, dann erfolgt die Rückgabe also in den Registern R22<tt>-</tt>R25 (LSB zuerst). Bei einem <tt>short</tt> sind es die Register R24 und R25.

=Ablauf der Codegenerierung=

Die Code-Erzeugung durch avr-gcc geschieht in mehreren, voneinander unabhängigen Schritten. Diese Schritte sind für den Anwender nicht immer erkennbar, und es auch nicht unbedingt notwendig, sie zu kennen. Für ein besseres Verständnis der Code-Generierung und zur Einordnung von Fehlermeldungen ist eine Kenntnis aber hilfreich.

==Übersichts-Grafik==

[[Bild:Avr-gcc-1.png|Zusammenspiel zwischen avr-gcc und binutils]]

==Schritte der Codegenerierung==

Ohne die Angabe spezieller Optionen werden die Zwischenformate nur als temporäre Dateien angelegt und nach Beenden des gcc-Laufs wieder gelöscht. Dadurch fällt die Aufgliederung in Unterschritte nicht auf. In diesem Falle müssen Assembler und Linker/Locator auch nicht extra aufgerufen werden, sondern die Aufrufe erfolgen durch gcc.

;Precompileren: Alle Preprozessor-Direktiven werden aufgelöst. Dazu gehören Direktiven wie
<pre>
#include <avr/io.h>
#include "meinzeug.h"

#define MAKRONAME ERSATZTEXT

#if !defined(__AVR__)
#error einen Fehler ausgeben und abbrechen
#else
/* Alles klar, wir koennen loslegen mit C-Code fuer AVR */
#endif

MAKRONAME
</pre>
:Precompilieren besteht also nur aus reinem Textersatz: Auflösen von Makros, kopieren von anderen Dateien in die Quelle, etc.

;Compilieren: In diesem Schritt geschieht der eigentliche Compilier-Vorgang: <tt>avr-gcc</tt> übersetzt die reine, precompilierte C-Quelle (*.i): Die Quelle wird auf Syntax-Fehler geprüft, es werden Optimierungen gemacht, und das übersetzte C-Programm als Assembler-Datei in (*.s) gespeichert.

;Assemblieren: Der Assembler (<tt>avr-as</tt>) übersetzt den Assembler-Code (*.s) in das AVR-eigene Objektformat elf32-avr (*.o). Das Objekt enthält schon Maschinen-Code. Zusätzlich gibt es aber noch Lücken, die erst später gefüllt werden und Debug-Informationen und ganz viel anderes Zeug.

;Linken und Lokatieren: Der Linker (<tt>avr-ld</tt>) bindet die angegebenen Objekte (*.o) zusammen und löst externe Referenzen auf. Der Linker entscheidet anhand der Beschreibung im Linker-Script, in welchen Speicheradressen und [[#Sections|Sections]] die Daten landen: er ''lokatiert'' (von location, locate (en)). Module aus Bibliotheken (*.a) werden hinzugebunden (z.B. <tt>printf</tt>) und die elf32-avr Ausgabedatei (üblicherweise *.elf) erzeugt.

;Umwandeln ins gewünschte Objekt-Format: Ohne Angabe spezieller [[#Kommandozeilen-Optionen|Optionen]] erzeugen Linker und Assembler ihre Ausgabe im Objektformat elf32-avr. Wird ein anderes Objektformat wie Intel-HEX (*.hex), binary (*.bin) oder srec (*.srec) benötigt, kann <tt>avr-objcopy</tt> dazu verwendet werden, um diese zu erstellen. Der Inhalt einzelner Sections kann gezielt umkopiert oder ausgeblendet werden, so daß Dateien erstellt werden können, die nur den Inhalt des Flashs (Section <tt>.text</tt>) oder des EEPROMs (Section <tt>.eeprom</tt>) repräsentieren. Durch das Umwandeln in ein anderes Objektformat gehen üblicherweise Informationen wie Debug-Informationen verloren.

:Es ist auch möglich, den Linker mit der Optione <tt>--oformat=...</tt> zu starten, damit er direkt das gewünschte Ausgabeformat erzeugt.

=Kommandozeilen-Optionen=
Die Codegenerierung bei <tt>avr-gcc</tt> 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.

Aus der Masse an GCC-Optionen kann hier nur ein kleiner Auszug der wichtigsten und am häufigsten verwendeten Optionen vorgestellt werden. Eine Auflistung aller GCC-Optionen mit Kurzbeschreibung umfasst knapp 1000 Zeilen ohne undokumentierte Optionen, versteht sich.

==Allgemeine Optionen für GCC==
; <tt>--help</tt>: Anzeige der wichtigsten Optionen
; <tt>--help -v</tt>: Überschüttet einen mit Optionen
; <tt>--target-help</tt>: Anzeige der wichtigsten maschinenspezifischen Optionen
; <tt>-O0</tt>: keine Optimierung
; <tt>-O1</tt>: Optimierung
; <tt>-Os</tt>: optimiert für Code-Größe
; <tt>-O2</tt>: stärkere Optimierung für bessere Laufzeit
; <tt>-g</tt>: erzeugt Debug-Informationen
; <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 (*.s)
; <tt>-E</tt>: nur Precompilat (<tt>*.i</tt>) erzeugen, kein Compilieren, kein Assemblieren, kein Linken
; <tt>-o <filename></tt>: legt den Name der Ausgabedatei fest
; <tt>-v</tt>: zeigt Versionsinformationen an und ist geschwätzig (verbose): Anzeige der aufgerufenen tools
; <tt>-I<path></tt>: Angabe eines weiteren Include-Pfads, in dem Dateien mit <tt>#include <...></tt> gesucht werden
; <tt>-E -dM <filename></tt>: Anzeige aller Defines
; <tt>-MM</tt>: Für die angegebenen Eingabe-Dateien wird eine Ausgabe erzeugt, die als [[make|Makefile]]-Fragment dienen kann und die Anhängigkeiten (dependencies) der Objekte von den Quellen/Headern beschreibt.
; <tt>-D<name></tt>: Definiert Makro <tt><name></tt>
; <tt>-D<name>=<wert></tt>: Definiert Makro <tt><name></tt> zu <tt><wert></tt>
; <tt>-U<name></tt>: Undefiniert Makro <tt><name></tt>
; <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>-Wa,<options></tt>: übergibt Komma-getrennte Liste <tt><options></tt> an den Assembler (<tt>avr-as</tt>)
:;<tt>-Wa,-a=<filename></tt>: Assembler erzeugt ein Listing mit Name <tt><filename></tt>
; <tt>-Wp,<options></tt>: übergibt Komma-getrennte Liste <tt><options></tt> an den Preprozessor
; <tt>-Wl,<options></tt>: übergibt Komma-getrennte Liste <tt><options></tt> an den Linker (<tt>avr-ld</tt>)
:;<tt>-Wl,-Map=<filename></tt>: Linker erzeugt ein Map-File mit Name <tt><filename></tt>
:;<tt>-Wl,--oformat=<format></tt>: Linker erzeugt Ausgabe im Format <tt><format></tt>, z.b. <tt>ihex</tt> für Intel-HEX-File
:;<tt>-Wl,--section-start<section>=<address></tt>: Linker legt die [[#Sections|Section]] <tt><section></tt> ab Adresse <tt><address></tt>, z.B: <tt>.eeprom=0x810001</tt>
; <tt>-Wall</tt>: gibt mehr Warnungen, aber immer noch nicht alle
; <tt>-pedantic</tt>: geht besonders pedantisch mit Code um
; <tt>-ansi</tt>: bricht mit einer Fehlermeldung ab, wenn kein ANSI-C verwendet wurde
; <tt>-ffreestanding</tt>: Das erzeugte Programm läuft nicht in einer Umgebung wie einer Shell. Der Prototyp von <tt>main</tt> ist
:<pre>void main (void);</pre>

==Maschinenspezifische Optionen für avr-gcc==
Maschinenabhängige Optionen beginnen immer mit '''-m'''
;-mmcu=xxx: Festlegen des Targets, für das Code generiert werden soll. Je nach Target werden unterschiedliche Instruktionen verwendet und andere Startup-Dateien (<tt>crtxxx.o</tt>) eingebunden. Spezielle Defines werden gesetzt, um in der Quelle zwischen den Targets unterscheiden zu können:
:<tt>
#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
</tt>

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.
{|
|- valign="top"
|
:{| {{Blauetabelle}}
|+ '''AVR classic, <= 8 kByte'''
|- {{Hintergrund1}}
!|mcu || Builtin define
|-
|avr2 ||<tt>__AVR_ARCH__=2</tt>
|-
|[[AT90S2313|at90s2313]] ||<tt>__AVR_AT90S2313__</tt>
|-
|at90s2323 ||<tt>__AVR_AT90S2323__</tt>
|-
|at90s2333 ||<tt>__AVR_AT90S2333__</tt>
|-
|at90s2343 ||<tt>__AVR_AT90S2343__</tt>
|-
|attiny22 ||<tt>__AVR_ATtiny22__</tt>
|-
|attiny26 ||<tt>__AVR_ATtiny26__</tt>
|-
|at90s4414 ||<tt>__AVR_AT90S4414__</tt>
|-
|at90s4433 ||<tt>__AVR_AT90S4433__</tt>
|-
|at90s4434 ||<tt>__AVR_AT90S4434__</tt>
|-
|at90s8515 ||<tt>__AVR_AT90S8515__</tt>
|-
|at90c8534 ||<tt>__AVR_AT90C8534__</tt>
|-
|at90s8535 ||<tt>__AVR_AT90S8535__</tt>
|-
|at86rf401 ||<tt>__AVR_AT86RF401__</tt>
|}
| 
:{| {{Blauetabelle}}
|+ '''AVR classic, > 8 kByte'''
|- bgcolor="#ccccff"
! |mcu ||Builtin define
|-
|avr3 ||<tt>__AVR_ARCH__=3</tt>
|-
|atmega103 ||<tt>__AVR_ATmega103__</tt>
|-
|atmega603 ||<tt>__AVR_ATmega603__</tt>
|-
|at43usb320 ||<tt>__AVR_AT43USB320__</tt>
|-
|at43usb355 ||<tt>__AVR_AT43USB355__</tt>
|-
|at76c711 ||<tt>__AVR_AT76C711__</tt>
|}
|}

----

{|
|- valign="top"
|
:{| {{Blauetabelle}}
|+ '''AVR enhanced, <= 8 kByte'''
|- bgcolor="#ccccff"
!|mcu || Builtin define
|-
|avr4 ||<tt>__AVR_ARCH__=4</tt>
|-
|[[Atmel Controller Mega8|atmega8]] ||<tt>__AVR_ATmega8__</tt>
|-
|atmega8515 ||<tt>__AVR_ATmega8515__</tt>
|-
|atmega8535 ||<tt>__AVR_ATmega8535__</tt>
|}
|
:{| {{Blauetabelle}}
|+ '''AVR enhanced, > 8 kByte'''
|- bgcolor="#ccccff"
!|mcu ||Builtin define
|-
|avr5 ||<tt>__AVR_ARCH__=5</tt>
|-
|[[Atmel Controller Mega16 und Mega32|atmega16]] ||<tt>__AVR_ATmega16__</tt>
|-
|atmega161 ||<tt>__AVR_ATmega161__</tt>
|-
|atmega162 ||<tt>__AVR_ATmega162__</tt>
|-
|atmega163 ||<tt>__AVR_ATmega163__</tt>
|-
|atmega169 ||<tt>__AVR_ATmega169__</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>
|}
|}

----

:{| {{Blauetabelle}}
|+ '''AVR, nur Assembler'''
|- bgcolor="#ccccff"
! |mcu ||Builtin define
|-
|avr1 ||<tt>__AVR_ARCH__=1</tt>
|-
|at90s1200 ||<tt>__AVR_AT90S1200__</tt>
|-
|attiny11 ||<tt>__AVR_ATtiny11__</tt>
|-
|attiny12 ||<tt>__AVR_ATtiny12__</tt>
|-
|attiny15 ||<tt>__AVR_ATtiny15__</tt>
|-
|attiny28 ||<tt>__AVR_ATtiny28__</tt>
|}

----

; -minit-stack=xxx: Festlegen der Stack-Adresse
; -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
; -mno-interrupts: Ändert den Stackpointer ohne Interrupts zu deaktivieren
; -mcall-prologues: Funktions-Prolog und -Epilog werden als Unterroutinen umgesetzt, um die Codegröße zu verkleinern
; -mtiny-stack: Nur die unteren 8 Bit des Stackpointers werden verändert
; -mno-tablejump: Für ein <tt>switch</tt>-Statement werden keine Sprungtabellen angelegt
; -mshort-calls: Verwendet <tt>rjmp</tt>/<tt>rcall</tt> (begrenzte Sprungweite) auf Devices mit mehr als 8 kByte Flash
; -msize: Ausgabe der Instruktonslängen im asm-File
; -mdeb: (undokumentiert) Ausgabe von Debug-Informationen für GCC-Entwickler
; -morder1: (undokumentiert) andere Register-Allokierung
; -morder2: (undokumentiert) andere Register-Allokierung

=Builtins=

Zur bedingten Codeerzeugung und zur Erkennung, welcher Compiler sich an der Quelle zu schaffen macht, sind folgende Builtins hilfreich.

Siehe auch: [[#Maschinenspezifische Optionen für avr-gcc|Maschinenspezifische Optionen]]

==Builtin Defines==

===GCC===
;<tt>__GNUC__</tt>: X wenn GCC-Version X.Y.Z
;<tt>__GNUC_MINOR__</tt>: Y wenn GCC-Version X.Y.Z
;<tt>__GNUC_PATCHLEVEL__</tt>: Z wenn GCC-Version X.Y.Z
;<tt>__VERSION__</tt>: "X.Y.Z" wenn GCC-Version X.Y.Z
;<tt>__GXX_ABI_VERSION</tt>: Version der ABI (Application Binary Interface)
;<tt>__STDC__</tt>: Ist 1, wenn Standard-C übersetzt wird
;<tt>__OPTIMIZE__</tt>: Optimierung ist aktiviert
;<tt>__NO_INLINE__</tt>: Ohne Schalter <tt>-finline</tt> resp. <tt>-finline-all-functions</tt> etc.
;<tt>__ASSEMBLER__</tt>: Definiert, falls GCC die Eingabe als Assembler-Code betrachtet und nicht compiliert. Weiterleitung an den Assembler.
;<tt>__cplusplus</tt>: Es wird C++ übersetzt (Quell-Endung <tt>*.cpp</tt>, <tt>*.c++</tt> oder Option <tt>-x c++</tt>).
;<tt>__FILE__</tt>: Löst auf zum Dateinamen der Quelldatei, in der das <tt>__FILE__</tt> steht.
;<tt>__LINE__</tt>: Löst auf zur Zeilennummer der Quelldatei, in der das <tt>__LINE__</tt> steht.
;<tt>__DATE__</tt>: Löst auf zum Datum (precompile-date)
;<tt>__TIME__</tt>: Löst auf zur Zeit (precompile-time)

===avr-gcc===
;<tt>__AVR</tt>: Definiert für Target avr, d.h. <tt>avr-gcc</tt> ist am Werk
;<tt>__AVR__</tt>: dito
;<tt>__AVR_ARCH__</tt>: codiert den AVR-Kern, für den Code erzeugt wird (Classic, Mega, ...).
;<tt>__AVR_XXXX__</tt>: Gesetzt, wenn <tt>-mmcu=xxxx</tt>.

==Builtin Variablen==
;<tt>__func__</tt>: Eine magische Variable, die den aktuellen Funktionsnamen enthält. Gerade so, als hätte man ihn selbst mit
:<pre>static const char __func__[] = "main";</pre>
:definiert.

=Sections=

Sections sind mit Fächern vergleichbar, in die Daten, Code, Debug-Informationen usw. einsortiert werden. Zur Section <tt>.text</tt> gehört z.B. der ausführbare Code, welcher letztendlich im Flash landet. Wo genau das ist, braucht man nicht zu wissen und es spielt auch keine Rolle, wo eine bestimmte Funktion landet.

Für 'normalen' Code und 'normale' Daten braucht man sich nicht um die Sections zu kümmern, sie werden von <tt>avr-gcc</tt> automatisch richtig zugeordnet. Für spezielle Anwendungen kann es aber notwendig sein, die Ablage in eine andere Section zu machen; etwa wenn man Daten im EEPROM lesen/schreiben will. Wie das genau gemacht wird, steht im Abschnitt "[[avr-gcc#Attribute|Attribute]]" und es gibt ein Beispiele in den Abschnitten
"[[avr-gcc#SRAM, Flash, EEPROM: Datenablage am Beispiel Strings|Datenablage am Beispiel Strings]]" und "[[Zufallszahlen mit avr-gcc|Zufall]]".

<center>
{| {{Blauetabelle}}
|+ '''Tabelle: Bedeutung der Sections bei <tt>avr-gcc</tt>'''
|- {{Hintergrund1}}
! |Section ||Ablage ||Betrifft ||Beschreibung
|-
|<tt>.text</tt> ||Flash ||Code ||normaler Programm-Code
|-
|<tt>.data</tt> ||SRAM ||Daten ||wird vom Startup-Code initialisiert, u.a. aus <tt>.progmem</tt>
|-
|<tt>.bss</tt> ||SRAM ||Daten ||wird vom Startup-Code zu 0 initialisiert
|-
|colspan="4" bgcolor="#bbbbff"|
|-
|<tt>.progmem</tt> ||Flash ||Daten ||wird vom Startup-Code nach <tt>.data</tt> kopiert
|-
|<tt>.eeprom</tt> ||EEPROM ||Daten ||Daten im EEPROM
|-
|<tt>.noinit</tt> ||SRAM ||Daten ||wird nicht initialisiert
|-
|colspan="4" bgcolor="#bbbbff"|
|-
|<tt>.init''n''</tt> ||Flash ||Code ||wird vor <tt>main</tt> ausgeführt, ''n'' = 0...9
|-
|<tt>.fini''n''</tt> ||Flash ||Code ||wird nach <tt>main</tt> ausgeführt, ''n'' = 9...0
|-
|<tt>.vectors</tt> ||Flash ||Code ||Vektor-Tabelle: Tabelle mit Sprüngen zur jeweiligen ISR
|-
|<tt>.bootloader</tt> ||Flash||Code ||für den Bootloader
|}
</center>
Der Anfang einer Section kann auch dem Linker mitgegeben werden, etwa wenn wie üblich <tt>avr-gcc</tt> als Treiber für den Linker verwendet wird:
avr-gcc ... -Wl,--section-start=.eeprom=0x810001
Damit beginnt Section <tt>.eeprom</tt> nicht an der (virtuellen) Adresse <tt>0x810000</tt>,
sondern ein Byte später.
Manche AVRs haben einen [[AVR-Errata|Silicon-Bug]], der bei Verwendung der EEPROM-Adresse 0 zu Fehlern führt.
Mit der obigen Linker-Option wird diese Adresse nicht mehr verwendet.



=Attribute=

Mit Attributen kann man die Codeerzeugung beeinflussen. Es gibt verschiedene Attribute, die auf Daten, Typen, und/oder Funktionen anwendbar sind.

'''Syntax:'''
<pre>
__attribute__ ((<name>))
__attribute__ ((<name1>, <name2>, ...))
__attribute__ ((<name> ("<wert>")))
</pre>

==Nützliche Attribute von GCC==

{| {{Blauetabelle}}
|+ '''Tabelle: Attribute von GCC''' (Auszug)
|- {{Hintergrund1}}
! |Attribut ||Funktionen ||Daten ||Typen ||Beschreibung
|-
| <tt>section ("<name>")</tt>
!| (x) || (x) || (x)
| Lokatiert nach Section <tt><name></tt>
|-
| <tt>noreturn</tt>
!| x || ||
| Die Funktion wird nie zurückkehren
|-
|<tt>inline</tt>
!| x || ||
|Funktion wird geinlinet falls möglich
|-
|<tt>noinline</tt>
!|x || ||
|Funktion wird keinesfalls geinlinet
|-
|<tt>packed</tt>
!| || x || x
|Datenablage in Strukturen erfolgt dicht, also ohne eventuelle Füllbytes
|-
|<tt>unused</tt>
!| || x ||
|Variable wird nicht verwendet, z.B. bei Funktionsparametern, die nicht gebraucht werden. Vermeidet entsprechende Warnungen.
|}

==Attribute von avr-gcc==

{| {{Blauetabelle}}
|+ '''Tabelle: Attribute von <tt>avr-gcc</tt>'''
|- {{Hintergrund1}}
! |Attribut ||Funktionen ||Daten ||Typen ||Beschreibung
|-
| <tt>progmem</tt>
!| x || x || x
| Lokatiert ins Flash
|-
| <tt>naked</tt>
!| x || ||
|Funktion wird ohne Prolog/Epilog erzeugt
|-
|<tt>interrupt</tt>
!| x || ||
|Hier nur wegen der Vollständigkeit erwähnt
|-
|<tt>signal</tt>
!| x || ||
|Hier nur wegen der Vollständigkeit erwähnt
|}

'''Beispiele:'''

<pre>
#define EEPROM __attribute__ ((section (".eeprom")))

const char EE_HALLO_WELT[] EEPROM = "Hallo Welt";
const int EE_wert EEPROM = 0x1234;

void __attribute__ ((noinline))
foo()
{
/* Code */
}
</pre>

=Dynamische Speicherallokierung=

[[Bild:Avr-ram.png|right|thumb|RAM-Layout für ein AVR mit 1kByte SRAM]]
Zur dynamischen Speicherallokierung stehen Standard-Funktionen wie <tt>malloc</tt> zur Verfügung.
Damit kann man zur Laufzeit Speicher anfordern und wenn man ihn nicht mehr benötigt, wieder freigeben.
Funktionen wie <tt>malloc</tt> und <tt>calloc</tt> sind jedoch recht aufwändig.
Die allokierten Speicherstücke werden intern in einer verketteten Liste verwaltet,
und das verbraucht wertvollen Platz im Flash und im SRAM sowie Laufzeit.

Resourcen-schonendere Möglichkeiten, zur Laufzeit an Speicher zu kommen,
bieteten <tt>__builtin_alloca</tt> und dynamische Arrays.
Der Speicher, der damit belegt wird, wird nicht auf dem Heap angelegt,
sondern im Frame der Funktion. Das ist wesentlich effektiver als die Standard-Methoden,
denn es muss nur ein Wert zum Framepointer addiert werden.
Den so erhaltenen Speicher braucht man auch nicht freizugeben. Das geschieht automatisch beim Verlassen der Funktion in deren Epilog, indem der Wert wieder vom Framepointer subtrahiert wird.

{{FarbigerRahmen|
Von der Verwendung ist der mittels <tt>__builtin_alloca</tt> und dynamischer Arrays erhaltene '''Speicher also wie eine lokale Variable, mitsamt den bekannten Regeln für den Gültigkeitsbereich'''.

Insbesondere darf dieser Speicher nicht mit <tt>return</tt> an die darüberliegende Funktion zurückgegeben werden, weil er dann nicht mehr gültig ist und ein Zugriff darauf zu einem
Laufzeitfehler führt!

Der Speicherbereich ist dort gültig, wo auch die Adresse einer 'normalen' lokalen Variablen gültig wäre, wenn diese an der gleichen Stelle definiert würde.

Das Programm/der Algorithmus muss daher beim Beschreiten dieses Wegs darauf angepasst sein.
}}

'''Verwendung:'''
<pre>
void function (size_t num_data)
{
// data_t hat man irgendwo selber definiert, oder es ist ein elementarer Typ
data_t * const p = (data_t * const) __builtin_alloca (num_data * sizeof (data_t));

// Mach was mit p[0] ... p[num_bytes-1]
...
}
</pre>
oder mittels eines dynamischen Arrays:
<pre>
void function (size_t num_data)
{
// data_t hat man irgendwo selber definiert, oder es ist ein elementarer Typ
data_t p[num_data];

// Mach was mit p[0] ... p[num_bytes-1]
...
}
</pre>

=C++=

Aus Effizienzgründen sollte der Einsatz von C++ 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."''

Zudem 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 <tt>avr-gcc</tt>. 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.

Interrupt-Service-Routinen (ISRs) sind C-Funktionen und werden definiert wie gehabt. Siehe auch [[#Interrupts|Interrupts]].
<pre>
#include <avr/io.h>
#include <avr/signal.h>

#if defined (__cplusplus)
extern "C" {
#endif /* __cplusplus */

SIGNAL (SIG_NAME)
{
/* machwas */
}

INTERRUPT (SIG_NAME)
{
/* mach was */
}

#if defined (__cplusplus)
}
#endif /* __cplusplus */
</pre>
<tt>__cplusplus</tt> ist ein Standard [[#Builtin Defines|GCC-Builtin-Define]].

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

=Code-Beispiele=
Dieser Abschnitt enthält Code-Schnippsel für <tt>avr-gcc</tt>. Es werden Besonderheiten besprochen, die für <tt>avr-gcc</tt> zu beachten sind.

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

==Zugriff auf Special Function Registers (SFRs)==

===Zugiff auf Bytes und Worte===
Auf SFRs wird generell über deren Adresse zugegriffen:
<pre>
// Liest den Inhalt von SREG an Adresse 0x5f
unsigned char sreg = *((unsigned char volatile*) 0x5f);
</pre>
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ß <tt>avr-gcc</tt> 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.

Um lesbaren, weniger fehleranfälligen und unter AVRs halbwegs portierbaren Code zu erhalten, gibt es Makrodefinitionen im Controller-spezifischen Header <tt>ioxxxx.h</tt>, der neben anderen Dingen mit <tt>avr/io.h</tt> includet wird:
<pre>
#include <avr/io.h>

...
// SREG lesen
uint8_t sreg = SREG;
...
// SREG schreiben
SREG = sreg;
</pre>
Die Bezeichner der SFRs sind die gleichen wie im Manual. Evtl verschafft ein Blick in den Header Klarheit. Dieser befinden sich in

<tt> <AVR_INSTALL_DIR>/avr/include/avr/io****.h</tt>

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: <tt>avr-gcc</tt> generiert die Zugriffe in der richtigen Reihenfolge.
uint16_t tcnt1 = TCNT1;

{{FarbigerRahmen|
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, was zu fehlerhaften Resultaten führen kann. Entsprechende Codestücke müssen daher atomar gehalten werden!
}}

===Zugriff auf einzelne Bits===
Zugriff auf Bits geht wie gewohnt mit den Bitoperationen
<tt>&</tt> (and),
<tt>|</tt> (or),
<tt>^</tt> (xor) und
<tt>~</tt> (not)

Wieder gibt es Defines in den AVR-Headern, mit denen man Masken für den Zugriff erhalten kann, etwa:
<pre>
/* GIMSK / GICR */
#define INT1 7
#define INT0 6
#define IVSEL 1
#define IVCE 0
</pre>

Masken ergeben sich durch Schieben von <tt>1</tt> an die richtige Position:
<pre>
// Ports B_0 und B_1 als Ausgang
DDRB |= (1<<PB0) | (1<<PB1);
</pre>
erzeugt
<pre>
87 b3 in r24, 0x17
83 60 ori r24, 0x03
87 bb out 0x17, r24
</pre>

Etwas anders sieht der Code aus, wenn die Bits einzeln gesetzt werden und das Register im bitadressierbaren Bereich liegt (SRAM <tt>0x20</tt> bis <tt>0x3f</tt> resp. I/O <tt>0x0</tt> bis <tt>0x1f</tt>):
<pre>
// Ports B_0 und B_1 als Ausgang
DDRB |= (1<<PB0);
DDRB |= (1<<PB1);
</pre>
erzeugt
<pre>
b8 9a sbi 0x17, 0
b9 9a sbi 0x17, 1
</pre>
{{FarbigerRahmen|
Auch hier ist zu beachten, daß es Probleme geben kann, wenn nicht atomarer Code erzeugt wird, weil der AVR-Befehlssatz nicht mehr hergibt:
<pre>
// toggle PORT B_0: wechseln 0 <--> 1
PORTB ^= (1<<PB0);
</pre>
ergibt
<pre>
88 b3 in r24, 0x18
; Wenn hier ein Interrupt auftritt, in dessen ISR PORTB verändert wird,
; dann wird die Änderung durch die letzte Instruktion wieder überschrieben!
91 e0 ldi r25, 0x01
; dito
89 27 eor r24, r25
; dito
88 bb out 0x18, r24
</pre>
}} 

Auch das Lesen einzelner Port-Pins geht über das Maskieren von SFRs:
<pre>
DDRB &= ~(1 << PB2); // PortB.2 als INPUT

if (PINB & (1 << PB2))
// PortB.2 ist HIGH
else
// PortB.2 ist LOW

if (!(PINB & (1 << PB2)))
// PortB.2 ist LOW
else
// PortB.2 ist HIGH
</pre>

==Interrupts==

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 die Includes und die Makros:
<pre>
#include <avr/io.h>
#include <avr/signal.h>

SIGNAL (SIG_OUTPUT_COMPARE1A)
{
/* ISR-Code */
}

INTERRUPT (SIG_OUTPUT_COMPARE1B)
{
/* ISR-Code */
}
</pre>

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

{{FarbigerRahmen|
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.
SIGNAL (SIG_OUTPUT_COMPARE1A ) // !!! Macht NICHT das, was man will (Blank am Ende)!!!
}}

;<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.

{{FarbigerRahmen|Dauert die ISR zu lange und wird sie nochmals von ihrem eigenen IRQ unterbrochen, stürzt man ab.}}

Nachschlagen kann man den Namen in
:<tt><GCC_HOME>/avr/include/avr/ioxxxx.h</tt>

===Interrupts aktivieren===

Damit eine ISR überhaupt zur Ausführung kommt, müssen drei Bedingungen erfüllt sein
* Interrupts müssen global aktiviert sein
* Der entsprechen IRQ muss aktiviert worden sein
* Das zum IRQ gehörende Ereignis muss eintreten
<pre>
#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();
</pre>
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.

===default Interrupt===

Für nicht implementierte Interrupts macht <tt>avr-gcc</tt> in die Vektortabelle einen Eintrag,
der zu <tt>__bad_interrupt</tt> (definiert im Startup-Code <tt>crt*.o</tt>) springt
und von dort aus weiter zu Adresse 0.
Dadurch läuft der AVR wieder von neuem los, wenn ein Interrupt auftritt,
zu dem man keine ISR definiert hat
 allerdings ohne die Hardware zurückzusetzen wie bei einem echten Reset.

Möchte man diesen Fall abfangen, dann geht das über eine globale Funktion
namens <tt>__vector_default</tt>:
<pre>
#include <avr/signal.h>

SIGNAL (__vector_default)
...
</pre>
Damit wird von <tt>__bad_interrupt</tt> aus nicht nach Adresse 0 gesprungen,
sondern weiter zu <tt>__vector_default</tt>, welches durch <tt>SIGNAL</tt> oder
<tt>INTERRUPT</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]]".

===ISR mit eigenem Prolog/Epilog===

Wenn man in einer ISR komplett eigenes Zeug machen will,
dann definiert man eine nackte Funktion.
Mit <tt>naked</tt> befreit man die Routine vom Standard-Prolog/Epilog.
{{FarbigerRahmen|
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.
}}
<pre>
#include <avr/io.h>

void __attribute__ ((naked))
SIG_OVERFLOW0 (void)
{
/* Port B.6 = 0 */
/* Diese Instruktion verändert nicht das SREG und kein anderes Register */
/* so daß der eigentliche Code nur 1 Befehl lang ist */
__asm__ __volatile (
"cbi %0, %1" "\n\t"
"reti"
:
: "M" (_SFR_IO_ADDR (PORTB)), "i" (6)
);
}
</pre>
Die ISR sieht dann so aus:
<pre>
__vector_9:
c6 98 cbi 0x18, 6
18 95 reti
</pre>

Wiederum kann man als Funktionsname <tt>__vector_default</tt> nehmen,
um nicht-implementierte IRQs abzufangen:
<pre>
void __attribute__ ((naked))
__vector_default (void)
...
</pre>

==SRAM, Flash, EEPROM: Datenablage am Beispiel Strings==
Die Programmiersprache C kennt selber keine Strings; das einzige, was C bekannt ist, ist der Datentyp <tt>char</tt>, der ein einzelnes Zeichen repräsentiert.
===Darstellung in C===
Ein String im Sinne von C ist ein Array von Charactern bzw. ein Zeiger auf den Anfang des Arrays. Die einzelnen Zeichen folgen im Speicher direkt aufeinander und werden in aufsteigenden Adressen gespeichert. Am String-Ende folgt als Abschluss der Character <tt>'\0'</tt>, um das Ende zu kennzeichnen. Dies ist besonders bei der Berechnung des Speicherplatzes für Strings zu berücksichtigen, denn für die 0 muss auch Platz reserviert werden.

===Bestimmen der Stringlänge===
<pre>
/* Bestimmt die Laenge des Strings ohne die abschliessende '\0' zu zaehlen */
unsigned int strlength (const char *str)
{
unsigned int len = 0;

while (*str++)
len++;

return len;
}
</pre>

Die Stringlänge kann auch mit der Standard-Funktion <tt>strlen</tt> bestimmt werden, deren Prototyp sich in <tt>string.h</tt> befindet:
<pre>
#include <string.h>
size_t strlen (const char*);
</pre>

===String im Flash belassen===
Oftmals werden Strings nur zu Ausgabezwecken verwendet und nicht verändert. Verwendet man Sequenzen der Gestalt
<pre>
char *str1 = "Hallo Welt!";
char str2[] = "Hallo Welt!";
</pre>
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 <tt>avr-gcc</tt> anhand der Adresse nicht unterscheiden, ob diese ins SRAM, ins Flash oder ins EEPROM zeigt.
<pre>
#include <avr/pgmspace.h>

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

unsigned int strlen_P (const prog_char *str)
{
unsigned int len = 0;

while (1)
{
char c = (char) pgm_read_byte (str);
if ('\0' == c)
return len;
len++;
str++;
}
}

void foo()
{
unsigned int len;
len = strlen_P (str3);
len = strlen_P (PSTR("String im Flash"));
}
</pre>

===String ins EEPROM legen===
Dies geht nach dem gleichen Muster, nach dem Strings ins Flash gelegt werden. Der Zugriff wird vergleichsweise langsam, denn der EEPROM ist langsamer als SRAM bzw. Flash.
<pre>
#include <avr/eeprom.h>

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

unsigned int strlen_EE (const char *str)
{
unsigned int len = 0;

while (1)
{
char c = (char) eeprom_read_byte (str);
if ('\0' == c)
return len;
len++;
str++;
}
}
</pre>

==Reset auslösen==
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 0 zu springen mit
goto *((void**) 0);
initialisiert zwar den Controller von neuem, aber es macht keinen wirkliches RESET mit Zurücksetzen der Hardware und allen I/O-Registern.

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:
<pre>
#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...
</pre>

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:
* Power-On Reset
* External Reset
* Brown-Out Reset
* Watchdog Reset

Soll der Inhalt von Variablen einen Reset überleben – eine Variable also nicht initialisiert werden – dann geht das so:
<pre>
#include <avr/io.h>

// status informiert z.B. darüber, ob wir selber den Watchdog ausgelöst haben
// oder nicht, oder andere Informationen
unsigned char status __attribute__ ((section (".noinit")));

void main (void)
{
// Wert von MCUSCR merken, möglichst früh im Programm
unsigned char mcucsr = MCUCSR;

// MCUCSR zurücksetzen
MCUCSR = 0;

// Watchdog-Reset
if (mcuscr & (1 << WDRF))
{
// status auswerten
}

// Power-On Reset: status auf definierten Wert setzen
if (mcuscr & (1 << PORF))
{
status = 0;
}

// status auswerten
...
}
</pre>

== Frühe Codeausführung vor main()==

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
* setzen des Stackpointers
* Vorbelegung globaler Datenobjekte: Daten ohne Initializer werden zu 0 initialisert (Section <tt>.bss</tt>). Für Daten mit Initializer (Section <tt>.data</tt>) werden die Werte aus dem Flash ins SRAM kopiert.
* Initialisierung von Registern wie R1, in dem bei <tt>avr-gcc</tt> immer die Konstante 0 gehalten wird.

Im Linker-Script werden Sections von <tt>.init0</tt> bis <tt>.init9</tt> definiert, die nacheinander abgearbeitet werden. Erst danach wird <tt>main</tt> betreten. Um Code früh auszuführen, legt man die Funktion in eine dieser Sections:
<tt>
/* !!! never call this function !!! */
void __attribute__ ((naked, section (".init3")))
code_init3 (void)
{
/* Code */
}
</tt>
Zu beachten ist dabei
* Eine so definierte Funktion darf keinesfalls aufgerufen werden!
* 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, <tt>avr-gcc</tt> 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 angezeigt oder die Implementierung in einem eigenen Assembler-Modul, das dazu gelinkt wird. Der erzeugte Code ist im List-File zu überfrüfen.
* Werden mehrere Funktionen in die gleiche init-Section gelegt, ist die Reihenfolge ihrer Ausführung nicht spezifiziert und i.a. nicht die gleiche wie in der Quelle.
Unbenutzte init-Sections haben die Nummern 0, 1, 3 und 5 bis 8. Die verbleibenden werden vom Startup-Code verwendet:
;<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>

=Includes=

Die mit
#include <...>
angegebenen Includes werden von <tt>avr-gcc</tt> in den
mit der Option '<tt>-I</tt>' anegegenen Pfaden gesucht.
Dem Compiler bekannt ist der Pfad <tt><GCC_HOME>/avr/include</tt>.
Gibt man z.B. an
#include <stdio.h>
dann wird automatisch in diesem Verzeichnis nach <tt>stdio.h</tt> gesucht.
In dem Verzeichnis stehen Standard-Includes die benötigt werden, wenn man libc-Funktionen
oder mathematische Funktionen verwendet.
AVR-spezifische Dinge stehen im Unterverzeichnis <tt>avr</tt>, etwa:
#include <avr/io.h>
{{FarbigerRahmen|
Als Pfad-Separator wird immer ein '''<tt>/</tt>''' verwendet, auch auf Windows-Betriebssystemen! Also kein '''<tt>\</tt>''' !
}}

==Standard==

ctype.h character conversion macros and ctype macros
errno.h provides symbolic names for various error codes
inttypes.h Use [u]intN_t if you need exactly N bits.
These typedefs are mandated by the C99 standard.
math.h mathematical functions
setjmp.h The C library provides the setjmp() and longjmp() functions
to jump directly to another (non-local) function.
stdio.h Standard IO facilities
stdlib.h Declares some basic C macros and functions as defined by
the ISO standard, plus some AVR-specific extensions
string.h perform string operations on NULL terminated strings

==AVR-spezifisch==

Die AVR-spezifischen Includes finden sich wie gesagt im Unterverzeichnis <tt>avr</tt>.
Die meisten dort befindlichen Header wird man nie direkt durch Angabe im C-File erhalten,
sondern durch Angabe von
#include <avr/io.h>
Dadurch werden z.B. genau der I/O-Header eingebunden, der zum AVR-Modell passt, also
*<tt>avr/iom8.h</tt> für [[ATmega8]],
*<tt>avr/iotn2313.h</tt> für ATtiny2313,
*<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,
kann ein Blick dorthin hilfreich sein, um die Namen von [[SFR|SFRs]]
oder Signals nachzuschlagen.
Diese Header werden im folgenden nicht alle einzeln aufgelistet.
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>
<pre>
avr/boot.h Bootloader Support
avr/crc16.h Prüfsumme CRC16
avr/delay.h Verzögerungsschleife - loops for small accurate delays
avr/eeprom.h EEPROM-Routinen
avr/ina90.h Kompatibilität mit IAR-AVR-Compiler
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/portpins.h Makros für Port-Pins
avr/signal.h Makros SIGNAL() und INTERRUPT(), ...
avr/sleep.h Power-Safe
avr/twi.h I2C
avr/wdt.h Watchdog
</pre>

=Optimierungen, Tipps & Tricks=

Beim Programmieren in C möchte man sich möglichst wenig mit der Codeerzeugung selbst auseinandersetzen. Man verwendet ja gerade deshalb einen Compiler und programmiert nicht in Assembler, weil man sich nicht um Register-Belegungen o.ä. kümmern will, sondern nur um die zu lösende Aufgabe.
GCC erzeugt zwar recht guten Code, aber er ist nicht perfekt. Gerade auf Systemen wie AVR mit nur sehr begrenzten Resourcen muss man daher dem Compiler hilfreich zur Seite stehen, wenn man noch dichteren/schnelleren Code erhalten möchte.

Um das Ergebnis zu beurteilen, hilft ein Blick ins Listfile.
Siehe dazu auch die Abschnitte
"[[Hallo Welt für AVR (LED blinken)#Listfile erstellen|Listfile erstellen]]"
und
"[[Hallo Welt für AVR (LED blinken)#Die Größe ermitteln|Die Größe ermitteln]]"
im [[Hallo Welt für AVR (LED blinken)|Hallo Welt für AVR]].

==Optimierungsgrad==
Als Optimierungsgrad erweist sich <tt>-Os</tt> (Optimize for Size) als der beste, evtl. noch <tt>-O2</tt>. Ohne Angabe eines Optimierungsgrades wird nicht optimiert, was gleichbedeutend mit der Option <tt>-O0</tt> ist. Abzuraten ist von der maximalen Optimierung <tt>-O3</tt>, die wegen function inlining und loop unrolling zu sehr breitem Code führt und für AVR absolut nicht angesagt ist.

==Vermeide printf, scanf, malloc==
Funktionen von diesem Kaliber sind die absoluten Platz- und Zeitfresser.

Alternativen findet man reichlich in der <tt>avr-libc</tt> wie <tt>itoa</tt> und <tt>atoi</tt>.
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]]".

==Konstante Strings ins Flash==
Konstante Strings, wie sie zu Ausgabezwecken Verwendung finden, werden im Programm oft nicht verändert und brauchen nicht SRAM zu belegen (und damit auch Flash, von wo aus sie vom Startup-Code ins SRAM kopiert werden), sondern gehören ins Flash!

Entsprechende Routinen, um auf Strings im Flash zuzugreifen, tragen die Suffix <tt>_P</tt>, wie z.B. <tt>strcmp_P</tt> mit dem Prototyp
extern int *strcmp_P (char *, const prog_char *)
Die Implementierungen befinden sich in der <tt>avr-libc</tt>.

'''Anwendung:'''
<pre>
#include <avr/pgmspace.h>

const prog_char str_p[] = "Ein String im Flash";
const char str2_p[] PROGMEM = "Noch ein String im Flash";
...
// String im SRAM mit String im Flash vergleichen
if (!strcmp_P (str_sram, str_p))
{
// mach was bei Gleichheit
}
...
}
</pre>

===Sprungtabelle===
Genauso macht man auch eine Sprungtabelle, um anhand von Kommando-Strings dazugehörige Funktionen ausführen zu lassen:
<pre>
#include <avr/pgmspace.h>

int func1 (int arg)
{
...
}

#define TEXT_LEN 15

// Die Kommandostruktur
typedef struct
{
int (*func)(int); // Zeiger auf die auszuführende Funktion
int arg; // das Argument, das mitübergeben wird
char text[1+TEXT_LEN]; // Text, maximal TEXT_LEN Zeichen lang
} command_t;

// Das Array mit den Kommandos.
// Die funcx sind vom Prototyp (z.B. func1 oben)
// int funcx (int arg);
const command_t commands[] PROGMEM =
{
{ func1, 0, "Befehl 1" },
{ func2, 3, "Befehl für func2" }
};

// Sucht in commands[] nach text und führt gegebenenfalls
// die dazugehörige Funktion funcx mit Argument arg aus.
// Liefert den Rückgabewert von funcx
// oder -1, falls text nicht gefunden wurde.
int execute (const char *text)
{
// Schleifenvariable
unsigned char i;

// Wandert durch das Array mit Kommando-Strukturen
const command_t * cmd = commands;

// sizeof wird von gcc ausgewertet und ist wie eine Konstante,
// denn beide sizeofs sind zur Compilezeit bekannt
for (i=0; i < sizeof(commands) / sizeof(command_t); i++)
{
// Ist das der gesuchte String?
if (strcmp_P (text, cmd->text))
{
// Nein, dann weitersuchen
cmd++;
continue;
}

// Ja
int (*func)(int), arg;

// Dann Funktionszeiger und Argument besorgen,
func = (int(*)(int)) pgm_read_word (& cmd->func);
arg = (int) pgm_read_word (& cmd->arg);

// Funktion ausführen und deren Wert zurückliefern
return func (arg);
}

// text ist nicht in commands
return -1;
}
</pre>

Nachteil dabei ist, daß jeder String den maximalen Platz von TEXT_LEN+1 Zeichen belegt.
Falls man da noch weiter sparen will, dann kann man die Strings wieder ins Flash legen und ihre Adresse in der Struktur merken. Dadurch belegt ein String nur noch Länge+3 Zeichen (+3 wegen 1 Endezeichen und 2 Bytes für seine in der Struktur gemerkte Adresse). Die Definition der Tabelle wird aber umständlicher, weil jeder String einzeln angegeben werden muss:
<pre>
#include <avr/pgmspace.h>

// Die Kommandostruktur
typedef struct
{
...
char *text; // Zeiger auf Text
} command_t;

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

const command_t commands[] PROGMEM =
{
{ func1, 0, str_1 },
{ func2, 3, str_2 }
};

// Sucht in commands[] nach text und führt gegebenenfalls
// die dazugehörige Funktion funcx mit Argument arg aus.
// Liefert den Rückgabewert von funcx
// oder -1, falls text nicht gefunden wurde.
int execute (const char *text)
{
// Schleifenvariable
unsigned char i;

// Wandert durch das Array mit Kommando-Strukturen
const command_t * cmd = commands;

// sizeof wird von gcc ausgewertet und ist wie eine Konstante,
// denn beide sizeofs sind zur Compilezeit bekannt
for (i=0; i < sizeof(commands) / sizeof (command_t); i++)
{
const prog_char * text_P;

// Liest die Startadresse von str_x
text_P = (const prog_char *) pgm_read_word (& cmd->text);

// Ist das der gesuchte String?
if (strcmp_P (text, text_P))
{
...
</pre>

==Lokale Variablen verwenden==

Beim Manipulieren globaler Variablen kann es günstig sein, diese in eine lokale Variable zu kopieren, dort zu verändern, und sie danach wieder zu schreiben
<pre>
char var;

void foo1()
{
var++;
if (var > 10)
var = 1;
}
</pre>
Dadurch wird einmal unnötig gespeichert (der dritte Befehl kann vermieden werden).
<pre>
foo1:
lds r24,var ; *movqi/4 [length = 2]
subi r24,lo8(-(1)) ; addqi3/2 [length = 1]
sts var,r24 ; *movqi/3 [length = 2]
cpi r24,lo8(11) ; cmpqi/2 [length = 1]
brlt .L3 ; branch [length = 1]
ldi r24,lo8(1) ; *movqi/2 [length = 1]
sts var,r24 ; *movqi/3 [length = 2]
.L3:
ret
</pre>
Indem man eine lokale Variable (<tt>var2</tt>) verwendet für die Änderung von <tt>var</tt> vermeidet man dies:
<pre>
char var;

void foo2()
{
char var2 = var;

var2++;
if (var2 > 10)
var2 = 1;

var = var2;
}
</pre>
Dadurch wird erst am Ende gespeichert. <tt>var2</tt> lebt in Register <tt>r24</tt>.
<pre>
foo2:
lds r24, var ; *movqi/4 [length = 2]
subi r24,lo8(-(1)) ; addqi3/2 [length = 1]
cpi r24,lo8(11) ; cmpqi/2 [length = 1]
brlt .L2 ; branch [length = 1]
ldi r24,lo8(1) ; *movqi/2 [length = 1]
.L2:
sts var, r24 ; *movqi/3 [length = 2]
ret
</pre>

Bei diesem einfachen Beispiel spart man lediglich eine Instruktion. Bei komplexeren Rechnungen oder längeren Datentypen kann es aber durchaus lohnender sein, in lokale Register zu kopieren.

==Arithmetik==

=== Daten zerlegen/zusammensetzen ===

In systemnahen Programmen hat man oft was Problem, auf die einzelnen Bytes oder Bitfelder einer grösseren Datenstruktur zuzugreifen. Indem man sich ein Komposit baut, das die gewünschten Strukturen überlagert, kann man effizient z.B. auf Bytes zugreifen. Ausnahme sind Bitfelder, deren Verwendung etwas breiten Code ergibt. Bitfelder "von Hand" zu manipulieren, ist da manchmal effizienter, führt jedoch zu schlecht lesbarem Code.
<pre>
typedef ... foo_t;

typedef union
{
unsigned char byte[4]; // Zugriff als Bytes (8 Bit)
unsigned short word[2]; // Zugriff als Words (16 Bit)
signed long slong; // Zugriff als signed long (32 Bit)

struct // Zugriff auf einzelne Bitgruppen
{
unsigned bit_0_3 : 4; // 4 Bits (0..3)
unsigned bit_4_8 : 5; // 5 Bits (4..8)
unsigned bit_9_21 : 13; // 13 Bits (9..21)
unsigned bit_22_31: 10; // 10 Bits (22..31)
};

foo_t foo; // Zugriff als foo-Struktur
} data_t;

...
{
data_t data;

data.b[2] = 12; // setzt byte 2 auf 12
data.bit_4_8 = 0x1f; // setzt bits 4..8 (5 Stück) alle auf 1

int anInt = data.foo.anInt; // liest ein Feld von foo (hier ein int)
...
}
</pre>

===libgcc2 verwenden===

In der libgcc2 sind einige Arithmetik-Routinen in Assembler implementiert. Dazu gehören ein paar Algorithmen zu Division (mit Rest) und Multiplikation.

Von diesen Algorithmen werden durch die avr-libc jedoch nur zwei Strukturen und Funktionen veröffentlicht: <tt>div_t</tt> und <tt>ldiv_t</tt> resp. die Funktionen <tt>div()</tt> und <tt>ldiv()</tt>. Siehe dazu deine Dokumentation zur avr-libc. Damit kann man Quotient und zusätzlich den Rest bei einer Division 16/16 bzw. 32/32 berechnen lassen; den Rest bekommt man quasi kostenlos als Nebenprodukt. Das ist praktisch, wenn man z.b. eine Zahl in Dezimaldarstellung umwandeln möchte oder von/nach [[BCD]].

Zusätzlich zu den via avr-libc veröffentlichten Funktionen gibt es aber noch Routinen, die z.B. auf 8-Bit-Werten operieren oder mit <tt>unsigned</tt> Typen und dementsprechend effizienter sind.

'''Beispiel: Umwandeln nach Dezimalstring'''

Hier ein Beispiel, das Division mit Rest für <tt>unsigned short</tt> verwendet, um eine 16-Bit-Zahl in Dezimaldarstellung zu wandeln:

<pre>
// Struktur definieren und Funktion bekannt machen
typedef struct
{
unsigned short quot;
unsigned short rem;
} udiv_t;

extern udiv_t udiv (unsigned short, unsigned short) __asm__("__udivmodhi4");

// 5 Ziffern (0...65535) und evtl. noch eine führende 0
#define DIGITS 6

// +1 wegen String-Ende (wird im Startup auf 0 gesetzt)
char string[DIGITS+1];

// Wandelt zahl in Dezimaldarstellung um.
// Der return-Wert zeigt irgendwo ins string[]-Array.
// string[] wird verändert.
char* toString (unsigned short zahl)
{
// s zeigt auf das Ende von string
// string wird von hinten nach vorne gefüllt
char *s = string + DIGITS;

// qrem enthält Quotient (quot) und Rest (rem) der Divisionen
udiv_t qrem = {.quot = zahl};

do
{
// Division mit Rest durch 10
// quot: Ergebnis für den nächsten Durchlauf
// rem: Rest ist die Ziffer im 10er-System
qrem = udiv (qrem.quot, 10);

// Ziffer in Zeichen wandeln und speichern
*(--s) = '0' + qrem.rem;
}
while (0 != qrem.quot);

// Falls eine führende '0' gespeichert wurde: weg damit
// ausser zahl war selbst schon 0
if (*s == '0' && *(s+1) != '\0')
s++;

return s;
}
</pre>

Falls man eine Division und/oder Rest für 8-Bit braucht, dann geht für <tt>unsigned</tt> analog.

'''Beispiel: BCD-Umrechnung'''

Wandeln einer 8-Bit-Zahl <tt>0 <= num < 100</tt> nach [[BCD]]
<pre>
typedef struct
{
unsigned char quot; // Quotient
unsigned char rem; // Rest (remainder)
} udiv8_t;

extern udiv8_t udiv8 (unsigned char, unsigned char) __asm__ ("__udivmodqi4");

// Wandelt num nach BCD um, 0 <= num <= 99
// return-Wert ist dann 0x0 <= return <= 0x99
unsigned char to_bcd (unsigned char num)
{
udiv8_t qrem = udiv8 (num, 10);

return (unsigned char) (qrem.quot << 4) | qrem.rem;
}
</pre>

===Division durch Multiplikation===
===Vermeiden von float und double===

=Bugs=

;<tt>__builtin_return_address(0)</tt>: ist entgegen der Spezifikation nicht implementiert und liefert in der Regel ein falsches Ergebnis.
;gcc 4.x: In der 4er-Version gab es tiefgreifende interne Änderungen im Compiler; er ist noch instabil und kann momentan noch nicht für den Produktiv-Einsatz empfohlen werden (Stand 02/2006).

=Abkürzungen und Bezeichnungen=
; GCC: GNU Compiler Collection
; gcc: GNU C-Compiler
; GPR: '''G'''eneral '''P'''urpose '''R'''egister
; ISR: '''I'''nterrupt '''S'''ervice '''R'''outine
; IRQ: '''I'''nterrupt '''R'''e'''q'''uest
; Prolog/Epilog: Code am Anfang/Ende jeder Funktionen/ISR, der dazu dient, verwendete Register zu sichern, den Stack-Frame für lokale [[Variable|Variablen]] anzulegen (falls benötigt), Stackpointer zu setzen, zurück zu springen (<tt>ret</tt>, <tt>reti</tt>), etc.
; SFR: '''S'''pecial '''F'''unction '''R'''egister
; Target: Zielsystem, in unserem Falle avr

=Siehe auch=
* [[WinAVR]]
* [[Hallo Welt für AVR (LED blinken)]] - ein erstes Beispiel für avr-gcc
* [[Fallstricke bei der C-Programmierung]]
* [[Inline-Assembler in avr-gcc|Inline-Assembler]]
* [[Sourcevergleich]]
* [[AVR]]
* [[Compiler]]

*[[:Kategorie:Quellcode_C|C-Codebeispiele]]

=Weblinks=
* [http://gcc.gnu.org/ Offizielle Homepage von GCC (en)]
* [http://de.wikipedia.org/wiki/GNU_Compiler_Collection GCC in der deutschen Wikipedia]
* [http://sourceforge.net/projects/winavr/ WinAVR-Projekt bei sourceforge.net (en)]
* [http://cdk4avr.sourceforge.net/ avr-gcc und toolchain als Linux-Paket bei sourceforge.net (en)]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial avr-gcc-Tutorial auf mikrocontroller.net]
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux bei linuxfocus.org]
* [http://www.avrfreaks.net/AVRGCC/ avr-gcc bei avrfreaks.net (en)]
* [http://savannah.nongnu.org/projects/avr-libc/ Nützliche GCC Runtime-Libary]

=Autor=

--[[Benutzer:SprinterSB|SprinterSB]] 11:27, 7. Dez 2005 (CET)

[[Kategorie:Grundlagen]]
[[Kategorie:Microcontroller]]
[[Kategorie:Praxis]]
[[Kategorie:Quellcode C|!]]
[[Kategorie:Software]]

Programmer's Notepad

2006-03-20T11:20:08Z

Alexander.stohr:

Das '''Programmer's Notepad''' ist ein freier Editor im Stil von [[Microsoft Visual Studio]] 8 (z.B. Teil von MS VC++ Express), der derzeit ein begrenztes Subset der dort implementierten Funktionen beinhaltet. Das Projekt wird auf Sourceforge.net gehostet. [[WinAVR]] beinhaltet dieses Tool.

Avr

2006-03-20T11:17:19Z

Alexander.stohr: /* Siehe auch */ +WinAVR

[[Bild:AtmelController.jpg|thumb|Beispiel eines AVR Controllers]]
'''AVR''' ist eine 8-Bit [[Microcontroller]]-Familie mit RISC-Architektur.
Im Gegensatz zu vielen anderen Microcontroller-Architekturen hat die AVR-Architektur keine Vorgänger. Sie ist ein komplettes Neudesign, das Anfang der 90-Jahre an der Universität von Trondheim/Norwegen entwickelt und vom (bis heute einzigen) Hersteller [[Atmel]] aufgekauft wurde. Es gibt eine ganze Serie von AVR-Controllern. Sie alle werden ähnlich programmiert, haben vergleichbaren Befehlssatz und physikalische Eigenschaften, bieten jedoch unterschiedliche Features und Peripherie.

Es gibt zahlreiche und kostenlose Entwicklungssysteme in den Sprachen Basic, C/C++, Pascal und Assembler für diese Controller-Familie.

==Wofür steht AVR?==
"AVR" steht angeblich für ''Advanced Virtual RISC'' (in einem Paper der Entwickler des AVR-Kerns Alf Egin Bogen und Vegard Wollan). Laut [[Atmel]] bedeutet es nichts.

==Hardware==
AVR-Controller besitzen eine zweistufige Pipeline (fetch and execute), die es ermöglicht, die meisten Befehle innerhalb eines einzigen Prozessortaktes auszuführen. Dadurch ist ein AVR wesentlich schneller als etwa 8051-Controller, bei denen der Prozessortakt intern noch durch 12 geteilt wird.

*AVR-Kern
** Harvard-Architektur (getrennter Befehls- und Datenspeicher)
** 32 Register, kein Akkumulator, 3 Pointerregister
** EEPROM-Datenspeicher
** [[Watchdog]], [[Bootloader]]-Support, verschiedene Stromspar-Modi, Brownout-Erkennung, Interner Oszillator
** Lineares Speichermodell (keine Segmentierung)
** 8-Bit Architektur ist für Hochsprachen (C) optimiert
* In-System programmierbar: die Controller können sehr einfach über ein Programmierkabel (oft ISP-Kabel genannt), das mit dem PC verbunden wird, programmiert werden – auch dann, wenn sie sich nicht in einer Schaltung befindet.
* umfangreiche Peripherie
** 8- und 16-Bit-Timer/Counter mit [[PWM]], Capture/Compare, externe Betaktung, asynchrone Operation
** Kommunikation: [[UART|USART]], [[SPI]], [[I2C]] ([[TWI]])
** Analog-Comparator, Analog-Digital-Wandler
** unterschiedlichste externe und interne Interrupt-Quellen (UART, SPI, Timer, A/D-Wandler, Analog-Comparator, ...)
** JTAG (Debugerinterface)
* AVR Typen (AT90 "Classic AVR", ATtiny, ATmega)
* erhältlich in unterschiedlichen Gehäusen, idR Durchsteck und als [[SMD]]
* Viele Entwicklungsboards erhältlich, z.B. das Roboternetzboard [[RN-Control]]

==Einige Pinbelegungen der populärsten AVR-Controller==
(in etwa nach Leistungsfähigkeit sortiert)

* [[AT90S2313]]

[[Bild:at90s2313tiny.png|center]]

* [[Atmel Controller Mega8]]
* [[Atmel Controller Mega48 Mega88 Mega168]]

[[Bild:mega8kompatibel.png|center]]

* [[Atmel Controller Mega16 und Mega32]]

[[Bild:Mega1632.gif|center]]

* [[Atmel Controller Mega128]] ([[SMD]]-Chip)

[[Bild:mega128pin.gif|center]]

----

===Die AVR-Pin-Bezeichnungen und deren Funktion===
Die meisten Ports sind doppelt belegt und besitzen neben der normalen Port-Funktion noch eine Sonderfunktion. Die verschiedenen Pinbezeichnungen und Sonderfunktionen werden hier beschrieben:

{| {{Blauetabelle}}
|+ '''Tabelle: Die AVR-Pin-Bezeichnungen und deren Funktion'''

|- {{Hintergrund1}}
! colspan="2"| Versorgungs- und Referenzpins, Reset
|-
|'''VCC'''
| Versorgungsspannung von 2,7 Volt bis 6 V bei den L-Varianten (low power), ansonsten 4,5V bis 6V. Die nächste AVR-Generation soll ab 1,8 Volt funktionieren.
|-
|'''GND'''
|Masse
|-
|'''AREF'''
|Referenzspannung für den Analog-Digital-Wandler (kann auf 5V gesetzt werden). Auch die interne Bandgap-Referenzspannung kann über diesen Pin entstört werden (dann KEINE externe Spannung an diesen Pin geben (Kurzschluss)!).
|-
|'''AGND'''
|Alternative Masse, etwa um ein Verbindungspunkt mit GND zu haben und bei empfindlichen Messungen Masseschleifen zu vermeiden.
|-
|'''AVCC'''
|
Die Betriebsspannung für den Analog-Digital-Wandler (siehe Beschaltungsskizze). Die Pins AVCC, AGND und AREF sollten immer beschaltet werden, da es sonst passieren kann, dass Port A nicht richtig funktioniert, selbst wenn man den AD-Wandler nicht benutzt.
|-
|'''RESET'''
|Rücksetz-Eingang, intern über einen [[Pullup]] mit VCC verbunden. Ein LOW–Pegel an diesem Pin für die Dauer von mindestens zwei Zyklen des Systemtaktes bei aktivem Oszillator setzt den Controller zurück. Rücksetzen der Ports erfolgt unabhängig von einem evtl. anliegenden Systemtakt.
|-
|'''PEN'''
|Programming Enable - Diesen Pin gibt es nur beim Mega128/64 u.ä. Wird dieser Pin beim Power-On Reset nach Masse gezogen, geht der Controller in den [[ISP]] Programmiermodus. Man kann ihn also alternativ zu Reset verwenden. In der Regel verwendet man aber die Reset-Leitung und PEN sollte man direkt mit VCC verbinden.

|- {{Hintergrund1}}
! colspan="2"| System-Takt
|-
|'''XTAL1'''
|Eingang des internen Oszillators zur Erzeugung des Systemtaktes bzw. Eingang für ein externes Taktsignal, wenn der interne Oszillator nicht verwendet werden soll bzw. Anschluss von Quarz/Keramik-Resonator/RC-Glied.
|-
|'''XTAL2'''
|Anschluss von Quarz oder Keramik-Resonator oder Ausgang des integrierten Oszillators zur Nutzung als Systemtakt (Je nach Fuse-Einstellungen).

|- {{Hintergrund1}}
! colspan="2"| Digitale bidirektionale I/O-Ports
|-
| colspan="2"| Jeder Pin der Ports kann individuell als Eingang oder Ausgang konfiguriert werden. Die I/O-Ports sind maximal 8 Bit breit und verfügen ja nach AVR-Typ über eine unterschiedliche Anzahl von Pins. An jedem als Eingang (Input) geschalteten Pin gibt es zuschaltbare [[Pullup]]-Widerstände, die teilweise auch bei aktivierter Sonderfunkton verfügbar sind.

Bei eingeschalteten Sonderfunktionen wie UART, SPI, ADC, etc. sind die entsprechenden Pins nicht als "normale" digitale I/O verwendbar, sondern dienen der Sonderfunktion. Die Anzahl der als I/O verwendbaren Pins ist auch abhängig von den Fuse-Einstellungen (Vorsicht beim Umstellen, Handbuch GENAU lesen!).
|-
|'''PA 0 – 7''' || Port A
|-
|'''PB 0 – 7''' || Port B
|-
|'''PC 0 – 7''' || Port C
|-
|'''PD 0 – 7''' || Port D
|-
|'''PE 0 – 7''' || Port E
|-
|'''PF 0 – 7''' || Port F
|-
|'''PG 0 – 7''' || Port G

|- {{Hintergrund1}}
! colspan="2"| Externe Interrupts
|-
| colspan="2"| Die PCINT-Interrupts gibt es nur für neuere AVRs wie den [[ATmega88]]. Falls die Anzahl an externen Interrupts nicht ausreicht, kann evtl. auch andere Hardware dafür eingesetzt werden, etwa der Analog-Comparator mit interner Bandgap-Referenz, falls er anderwärtig nicht gebraucht wird.
|-
|'''INT0''' ||Externer Interrupt 0
|-
|'''INT1''' ||Externer Interrupt 1
|-
|'''INT2''' ||Externer Interrupt 2
|-
|'''PCINTx''' ||Pin-Change Interrupt

|- {{Hintergrund1}}
! colspan="2"| [[Timer]] und [[PWM]]
|-
|'''T0'''
|Timer-Eingang. Timer kann gestartet, gestoppt oder getaktet werden
|-
|'''T1'''
|Timer-Eingang. Timer kann gestartet, gestoppt oder getaktet werden
|-
|'''OC0'''
|PWM bzw. Output Compare Ausgang des Timers 0
|-
|'''OC1A'''
|Ausgang für die Compare-Funktion des integrierten Zeitgeber- / Zählerbausteines
Der erste PWM-Ausgang des Timers1. Er kann zum Regeln der Bot-Motogeschwindigkeit benutzt werden.
|-
|'''OC1B'''
|Ausgang für die Compare-Funktion des integrierten Zeitgeber- / Zählerbausteines
Der zweite PWM-Ausgang des Timers1. Er kann zum Regeln der Bot-Motogeschwindigkeit benutzt werden.
|-
|'''ICP1'''
|Eingang für die Capture-Funktion des integrierten Zeitgebers / Zählerbausteines
|-
|'''OC2'''
|[[Pwm]] bzw. Output Compare Ausgang des Timers2. Er kann zum Regeln der Bot-Motogeschwindigkeit benutzt werden.
|-
|'''TOSC1, TOSC2'''
|TOSC1 und TOSC2 sind Eingänge für den asynchronen Modus von Timer2. Sie sind vorgesehen für den Anschluss eines externen Uhrenquarzes ( 32.768 kHz ). Damit lassen sich zum Beispiel sehr genaue Ein-Sekunden-Impulse für eine Uhr generien.

|- {{Hintergrund1}}
! colspan="2"| Analog-Digital-Wandler
|-
|'''ADC0''' bis '''ADC7'''
|Eingänge des AD-Wandlers. Spannungen können hier gemessen werden oder an den Analog-Komparator weiter geleitet werden.

|- {{Hintergrund1}}
! colspan="2"| Analog-Komparator
|-
|'''AIN0, AIN1'''
|Die beiden externen Eingänge des Analog-Komparators.
Mit AIN0(+) und AIN1(-) kann man zwei Spannungen miteinander vergleichen. Wenn die Spannung an AIN0 höher als bei AIN1 ist, liefert der Komparator "High", ansonsten ein "Low". Als interne Eingänge des Komparators können die Interne Bandgap-Referenzspannung oder Ausgänge des ADC-Multiplexers dienen.

|- {{Hintergrund1}}
! colspan="2"| Serielle Schnittstelle ([[UART|USART]])
|-
|'''RXD'''
|Eingang der Seriellen Schnittstelle (Receive Data), TTL-Pegel
|-
|'''TXD'''
|Ausgang Serielle Schnittstelle (Transmit Data), TTL-Pegel
|-
|'''XCK'''
|Externe Takt für den USART. Wird nur in Sonderfällen für den Takt benötigt.
USART ("Universal Synchronous/Asynchronous Receiver and Transmitter"). Das ist die serielle Schnittstelle, die zur Datenübertragung zwischen Mikrocontroller und PC genutzt wird. Zur bidirektionalen Übertragung werden zwei Pins am Controller benötigt: TXD und RXD. Über TXD ("Transmit Data") werden Daten gesendet, RXD ("Receive Data") dient zum Empfang.

|- {{Hintergrund1}}
! colspan="2"| [[SPI]]-Schnittstelle
|-
|'''SS'''
|SPI-Interface – wird beneötigt um den richtigen Slave am Bus zu wählen
|-
|'''MOSI'''
|SPI-Interface – Datenausgang (als Master) oder Dateneingang (als Slave), verwendet bei ISP (In-System-Programmierung)
|-
|'''MISO'''
|SPI-Interface – Dateneingang (als Master) oder Datenausgang (als Slave), verwendet bei ISP (In-System-Programmierung)
|-
|'''SCK'''
|SPI-Interface – Bustakt vom Master, verwendet bei ISP (In-System-Programmierung)

|- {{Hintergrund1}}
! colspan="2"| [[I2C|I2C]]-Schnittstelle ([[TWI]])
|-
|'''SDA'''
|I2C-Schnittstelle (Bus aus 2 Leitungen) Datenleitung
|-
|'''SCL'''
|I2C-Schnittstelle (Bus aus 2 Leitungen) Clockleitung

|- {{Hintergrund1}}
! colspan="2"| [[JTAG]]-Interface
|-
|'''TDI'''
|JTAG-Debug Interface - Über dieses Interface kann man den AVR programmieren und debuggen. Die Schnittstelle ist ähnlich wie die SPI Schnittstelle und hat getrennte Dateneingangs- und Datenausgangsleitungen sowie eine Taktleitung. TDI ist die Dateneingangsleitung
|-
|'''TDO'''
|JTAG-Debug Interface - TDO ist die Datenausgangsleitung des JTAG Interface
|-
|'''TMS'''
|JTAG-Debug Interface
|-
|'''TCK'''
|JTAG-Debug Interface
|}
----

== Timer der AVRs ==

Die Mikrocontroller der AVR-Familie besitzen je nach Typ eine unterschiedliche Anzahl an programmierbaren [[Timer|Timern]]. Bei den aktuellen ATmegas sind das mindestens ein 8-Bit Timer und bei größeren Ausführungen der Serie auch 16-Bit Timer. Die Timer werden immer Timerx benannt, wobei x für die Timernummer steht (also 0, 1, 2, usw.).
Die Konfigurationsmöglichkeiten sind von Timer zu Timer unterschiedlich.

'''Hinweis:''' Die folgenden Code-Beispiele sind in C programmiert und wurden für einen [[ATMega32|ATmega32]] entwickelt. Sie lassen sich also ohne große Änderungen auch auf anderen Mikrocontrollern der AVR-Familie einsetzen.

=== Allgemeine Funktionsweise ===
Timer funktionieren nach dem allgemeinen Prinzip, dass sie eine Ganzzahl (im weiteren als Zähler bezeichnet) je nach Betriebsmodus auf- oder abwärtszählen, d.h. inkrementieren bzw. dekrementieren.

Angenommen, der Timer arbeitet im einfachsten Betriebsmodus, dem normalen Modus (siehe [[Avr#Normaler Modus (Normal Mode)|Normaler Modus (Normal Mode)]]). Die Zählrichtung des Timers ist aufsteigend gerichtet. Je nach Auflösung, also 8-Bit oder 16-Bit, erreicht der Zähler irgendwann einen bestimmten Zustand. Möglich wäre, dass er überläuft, wenn z.B. bei einem 8-Bit Timer der Wert 255 inkrementiert wird (siehe Grafik).

[[Bild:AbstrakterZaehlvorgang.png]]

=== Der Prescaler ===
Der Prescaler (eng. = Vorteiler) kann dazu genutzt werden, den Takt, der den Timern zugeführt wird, zu verkleinern. U.a. kann man damit die Timer so konfigurieren, damit diese in den unterschiedlichsten Frequenzen takten. Hier eine Grafik die den Prescaler veranschaulicht:

[[Bild:Prescaler.png]]

Das obere Diagramm zeigt den Betrieb ohne Prescaler, das untere mit Prescaler. Die gestrichelte Linie zeigt, wann ein Interrupt eintritt.

Im Teil [[Avr#Die Betriebsmodi|Die Betriebsmodi]] wird weiter auf die praktische Verwendung des Prescalers eingegangen.

=== Die Betriebsmodi ===
Die AVR-Timer können in unterschiedlichen Betriebsmodi betrieben werden. Diese sind:
* Normaler Modus
* CTC Modus
* PWM

==== Normaler Modus (Normal Mode) ====
Der einfachste Betriebsmodus ist der normale Modus. Er funktioniert wie im Abschnitt "[[Avr#Allgemeine Funktionsweise|Allgemeine Funktionsweise]]" beschrieben. Die Zählrichtung des Timers ist immer aufsteigend, und irgendwann kommt es zu dem Interrupt Timer-Overflow (welcher in einer passend ISR aufgefangen werden kann). Im einfachsten Fall kann man diesen Modus in folgendem Diagramm darstellen:

[[Bild:NormalerModus_1.png]]

Der Zähler des Timers (im Diagramm oben, die aufsteigende und dann wieder zurückgesetzte Linie) ist in dem Register TCNTx gespeichert, wobei x für eine Zahl steht. Soll z.B. auf den Timer0 (siehe Datenblatt des jeweiligen Controllers) des Controllers zugegriffen werden, so ist an TCNT eine 0 anzuhängen, also TCNT0.
Wie lange es braucht, bis der Zähler einen Overflow auslöst, ist von der Taktfrequenz des Controllers, dem eingestellten Prescaler-Wert und von der Timerauflösung abhängig. Nun wäre es ja sehr unpraktisch, wenn wir den Zähler nicht anpassen könnten. Denn sonst müssten wir unsere Software die den Timer benutzt evtl. anpassen und viel rechnen um z.B. für 1000 ms zu schlafen. Deswegen kann auf den Zähler zugreifen und ihn vorladen bevor dieser wieder vom eigentlichen Timer hochgezählt wird. Dies veranschaulicht folgendes Diagramm:

[[Bild:NormalerModus_1_Vorladen.png]]

Dadurch kann man den Timer beeinflussen, und beeinflussen wie lange es dauert, bis ein Overflow auftritt. Um zu berechnen, welchen Wert wir vorladen müssen, kann man auch ein Java-Applet nutzen, siehe unter [[Avr#Weblinks|Weblinks Java Applet]].

Natürlich kann man das auch "von Hand" rechnen. Die Berechnung des Preloader- sowie Prescalerwerts bei Verwendung der Overflow-Interrupts, eines Prescalers von 64 (nicht alle Prescaler können verwendet werden) und eines Quarzes mit der Frequenz von 8 MHz sieht folgendermaßen aus (gesuchte Frequenz beträgt 1000 Hz unter der Verwendung des Timer0 eines ATmega32):
# <math>Prescale = Frequenz * 1000000 [Hz] = 8000000</math>
# Wir definieren den maximalen Zählerwert. Dieser ist bei einem 8-Bit Timer 256, bei einem 16-Bit Timer 65536. In unserem Fall ist der maximale Zählerwert 256, weil Timer0 verwendet wird.
# Nun wird die Variable ''Prescale'' (s.o.) durch den verwendeten Prescaler (64) geteilt (<math>8000000 Hz / 64 = 125000</math>).
# Als nächstes wird der im dritten Punkt errechnete Wert durch die gesuchte Frequenz geteilt <math>=125000 / 1000Hz = 125</math>.
# Nun wird mathematisch überprüft, ob der errechnete Wert aus dem vierten Punkt kleiner als der maximale Zählerwert ist. Trifft dies zu, so subtrahiert man den errechneten Wert vom maximalen Zählerwert (<math>= 256 - 125 = 131</math>).

Damit haben wir den Wert errechnet, der bei jedem Interrupt, den der Timer0 auslöst, in TCNTx (in diesem Fall TCNT0) nachgeladen werden muss, damit die Interrupts in dem gewünschten Zeitabstand von einer Millisekunde ausgelöst werden.

Allerdings bleibt zu bemerken, dass bei der Verwendung einer "ungeraden" Quarzfrequenz (z.B. 7,3728 MHz) der Timer mit einer bestimmten Ungenauigkeit arbeitet. Würden wir z.B. den Quarz oben mit einem Quarz mit 7,3728 MHz austauschen, so wäre die Fehlerrate 0,17%. Diese Ungeauigkeit varriert von verwendetem Prescaler zu Prescaler. D.h. wenn wir einen Prescaler von 1024 (und einer Quarzfrequenz von 8 MHz) verwendet hätten, so hätten wir eine inakzeptable Ungeauigkeit von 11,61%. Deswegen sollte sie eines der genannten Programme unter [[Avr#Weblinks]] verwenden, denn diese zeigen nur die bestmögliche Konfiguration an.

Die Fehlerrate kann natürlich auch ausgerechnet werden. Hier die Rechenschritte (sie sind erweiternd zu der oberen Berechnung):
# Als erstes wird mathematisch überprüft, ob der Preloaderwert (siehe fünften Schritt oben) größer als 1 ist.
# Trifft dies zu, so wird als nächstes die resultierende Frequenz errechnet. Die geschieht folgendermaßen: Der errechnete Preloaderwert aus der Rechnung oben wird vom maximalen Zählerwert subtrahiert, anschließend mit dem Prescaler multipliziert und dann das Ganze durch die Variable Prescale geteilt
<math>(256 - 131) \cdot 64 / 8\,000\,000 \mathrm{Hz} \cdot 1\,000\,000 = 1000</math>.
# Nun wird die gesuchte Frequenz vom errechneten Wert aus dem dritten Punkt subtrahiert und dann wiederum durch diese geteilt <math>(1000-1000) / 1000 = 0</math>. Damit läuft dieser Timer genau mit einer Fehlerrate von 0 %.

Betreibt man den Timer im Overflow-Modus, so muss man, wie bereits erwähnt, nach/bei jedem Overflow-Interrupt den Timer nachladen. Der Interrupt heißt in diesem Fall SIG_OVERFLOWx (x steht für die Nummer des Timers). Dieser muss in einer ISR abgefangen werden.

Zusammenfassend ein Beispielprogramm:

<pre>
/* Es wird der Timer2 (8-Bit) eines ATmega32 verwendet, der mit einem Quarz mit 7,3728 MHz
betrieben wird. Im Abstand von 0,001 ms erzeugt der Timer einen Interrupt, also eine
Frequenz von 1000000 Hz (oder 100 kHz). Der Timer wird auf einen Prescaler von 1 und
einem Preloader von 183 konfiguriert.*/

volatile uint8_t countTimer2; // Speichert den aktuellen Zählerwert

// ISR zum auffangen der Interrupts:
SIGNAL(SIG_SIG_OVERFLOW2)
{
countTimer2++;
TCNT2 = 183; // Nachladen
}

// Initialisierung:
TCCR2 = (1<<CS22); // Prescaler von 1
TCNT2 = 183; // Vorladen
TIMSK |= (1<<TOIE2); // Interrupts aktivieren und damit Timer starten
sei();

// Funktionen zum benutzen der Timer:
/** Diese Funktion nicht aufrufen. Wird von sleep_millisec aufgerufen.
Bei t=100 schläft die Funktion 1 ms. */
inline void sleep (uint8_t t)
{
// countTimer2 wird in der ISR oben inkrementiert
countTimer2 = 0;
while (countTimer2 < t);
}

/** Schläft x-Millisekunden. */
inline void sleep_millisec(uint16_t msec)
{
uint16_t i;
for(i=0; i<msec; i++) {
sleep(100);
}
}
</pre>
Allerdings wird auf diese leicht veraltete Technik nun nicht weiter eingegangen. Der Artikel wendet sich nun dem neueren "Compare Output"-Betriebsmodus zu.

Beim "Compare Output"-Betriebsmodus wird genauso ein Zähler hochgezählt. Allerdings wird der Zählerwert nach jeder Inkrementierung mit einem vom Benutzer festgelegten Wert verglichen. Entspricht der Zählerwert dem gespeicherten Wert, so kommt es zu einem Interrupt. Dieser Wert wird in das Register OCRx (x steht wieder für die Timernummer) gespeichert. Je nach Auflösung des Timers ist dieses Register 8-Bit oder 16-Bit breit.

Hinweis: Siehe CTC Modus unten. Dieser wird benötigt um den Timer entsprechend im "Compare Output"-Betriebsmodus vernünftig zu betreiben.

Hier ein typisches Diagramm dieses Betriebsmodus (Hinweis: Das Diagramm wurde unter Verwendung des CTC Modus erstellt. Für Begriffserklärung siehe CTC Modus):

[[Bild:NormalerModus_CompareMatch.png]]

Das Ausrechnen des Werts, der in OCRx geschrieben werden muss, damit Frequenz x entsteht, ist nicht sonderlich schwer. Man geht wie bei der Berechnung des Werts für den Overflow-Modus vor (s.o.) nur daß man das resultierende Ergebnis vom maximalen Zählerwert (bei 8-Bit Auflösung ist dieser 256, bei 16-Bit Auflösung 65536) subtrahiert. Das Ergebnis wird dann einmalig in das Register OCRx geschrieben. Mann muss also nicht wie beim Overflow-Modus den Timer nach jedem Interrupt nachladen. Der enstehende Interrupt heißt in diesem Fall SIG_OUTPUT_COMPAREx (x steht für die Nummer des Timers). Dieser muss in einer ISR abgefangen werden.

Wiederum zusammenfassend ein Beispielprogramm:

<pre>
/* Es wird der Timer2 (8-Bit) eines ATmega32 verwendet, der mit einem Quarz mit 7,3728 MHz
betrieben wird. Im Abstand von 0,001 ms erzeugt der Timer einen Interrupt, also eine Frequenz
von 1000000 Hz (oder 100 kHz). Der Timer wird auf einen Prescaler von 1 und einem OCR2-Wert
von 73 konfiguriert.*/

volatile uint8_t countTimer2; // Speichert den aktuellen Zählerwert

// ISR zum auffangen der Interrupts:
SIGNAL(SIG_OUTPUT_COMPARE2)
{
countTimer2++;
}

// Initialisierung:
TCCR2 = (1<<CS22) | (1<<WGM21); // Prescaler von 1 | CTC-Modus (siehe unten für Beschreibung)
OCR2 = 73; // Vergleichswert
TIMSK |= (1<<OCIE2); // Interrupts aktivieren und damit Timer starten
sei();

// Funktionen zum benutzen der Timer:
/** Diese Funktion nicht aufrufen. Wird von sleep_millisec aufgerufen.
Bei t=100 schläft die Funktion 1 ms. */
inline void sleep(uint8_t t)
{
// countTimer2 wird in der ISR oben inkrementiert
countTimer2 = 0;
while (countTimer2 < t);
}

/** Schläft x-Millisekunden. */
inline void sleep_millisec(uint16_t msec)
{
uint16_t i;
for(i=0; i<msec; i++) {
sleep(100);
}
}
</pre>

==== CTC Modus (Clear Timer on Compare Match mode) ====
Der CTC Modus ist eine Erweiterung des "Compare Output"-Betriebsmodus. Der CTC Modus wird z.B. für das obere Beispielprogramm benötigt. Wird der Timer nämlich im normalen Betriebsmodus betrieben, so ist seine Zählergrenze je nach Auflösung 255 oder entsprechend für die 16-Bit Timer. Erst wenn diese Grenze erreicht wurde, wird der Timer zurückgesetzt (also auf 0). Durch den CTC Modus wird der Timer augenblicklich automatisch nachdem ein "Compare Output"-Interrupt auftrat zurückgesetzt. Man kann also die maximalen Zählergrenze selber definieren.
Dieses Diagramm veranschaulicht den CTC Modus. Nach dem Interrupt wird der Timer sofort wieder zurückgesetzt.

[[Bild:NormalerModus_CompareMatch.png]]

==== PWM ====
Für PWM siehe [[Pwm]].

=== Registerübersicht ===

'''Hinweis:''' Diese Registertabelle wurde für den aktuellen [[Atmel Controller Mega16 und Mega32]] erstellt. Wenn Sie ein anderes Modell verwenden, kann es sein, dass ein oder mehrere Register nicht existieren, oder sie eine andere Bezeichnung haben.

{| {{Blaueschmaltabelle}} width=100%
|'''TIMSK'''
|-
|Mit diesem Register, der von allen Timern verwendet wird, lässt sich die Interruptausführung und Art des jeweiligen Timers bestimmen. 

{{Registertabelle8Bit|OCIE2|TOIE2|TICIE1|OCIE1A|OCIE1B|TOIE1|OCIE0|TOIE0}}

|-
|
*'''OCIE2 (Timer/Counter2 Output Compare Match Interrupt Enable''' Wenn dieses Bit gesetzt wird, wird der Timer/Counter2 Compare Match Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
*'''TOIE2 (Timer/Counter2 Overflow Interrupt Enable)''' Wenn dieses Bit gesetzt wird, wird der Timer/Counter2 Overflow Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
*'''TICIE1 (Timer/Counter1, Input Capture Interrupt Enable)''' Wenn dieses Bit gesetzt wird, wird der Timer/Counter1 Input Capture Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
*'''OCIE1A (Timer/Counter1 Output Compare A Match Interrupt Enable)''' Wenn dieses Bit gesetzt wird, wird der Timer/Counter1 Output Compare A Match Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
*'''OCIE1B (Timer/Counter1 Output Compare B Match Interrupt Enable)''' Wenn dieses Bit gesetzt wird, wird der Timer/Counter1 Output Compare B Match Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
*'''TOIE1 (Timer/Counter1 Overflow Interrupt Enable)''' Wenn dieses Bit gesetzt wird, wird der Timer/Counter1 Overflow Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
*'''OCIE0 (Timer/Counter0 Output Compare Match Interrupt Enable)''' Wenn dieses Bit gesetzt wird, so wird der Timer/Counter0 Compare Match Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
*'''TOIE0 (Timer/Counter0 Overflow Interrupt Enable)''' Wenn dieses Bit gesetzt wird, so wird der Timer/Counter0 Overflow Interrupt aktiviert (vorrausgesetzt die Interrupts sind global aktiviert).
|}

----

==Die Fusebits==
Fusebits nennt man bestimmte Bits zur Konfigurierung eines AVR-Controllers. Bei der Auslieferung neuer AVR Controller sind die Fusebits bereits vorkonfiguriert. In vielen Fällen kann man die Konfiguration unverändert belassen, je nach Controllertyp. Bei den Typen Mega xxx bestimmen einige Fusebits beispielsweise, dass der interne Taktgeber aktiviert ist. Möchte man dagegen einen externen Quarz anschließen oder die Taktfrequenz ändern, so müssen auch die Fusebits geändert werden. Auch das Deaktivieren des "[[On Chip Debugging]]" Modus ist oft notwendig, wenn man alle Ports ausnutzen möchte.

Die Fusebits werden in der Regel über die Software eingestellt, welche auch für das Übertragen des Programmcodes zuständig ist. Besonders einfach geht dies beispielsweise mit der Entwicklungsumgebung [[Bascom]]. Aber auch andere Programme wie [[PonyProg]] können für die Umstellung der Fusebits genutzt werden. Einmal eingestellte Fusebits bleiben bis zur erneuten Fusebit-Änderung erhalten. Der normale Programmiermodus verändert die Fusebits nicht.

Je nach AVR Controllertyp sind unterschiedliche Fusebits (Einstellungen) vorhanden. Die genaue Beschreibung findet man im jeweiligen Datenblatt. Da aber falsch gesetzte Fusebit-Einstellungen zu den häufigsten Problemen gehören, liste ich hier die Funktion der üblichen Fusebits nochmals genauer auf:

{| {{Blauetabelle}}
|'''CKSEL0, CKSEL1, CKSEL2, CKSEL3'''
|Die Kombination dieser 4 Fusebits bestimmt die Taktquelle des Controllers. Das kann eine interner Taktgenerator, ein Quarz, Quarzoszillator, RC-Glied und ähnliches sein.
|-
|'''JTAGEN'''
|Hiermit wird die "[[On Chip Debugging]]" Schnittstelle aktiviert bzw. deaktiviert. Das sind die Bits mit den Bezeichnungen TDI, TDO, TMS und TCK. Möchte man diese Pins als normalen Port nutzen, so muss diese Schnittstelle immer deaktiviert werden.
|-
|'''SUT0, SUT1'''
|Die sogenannte StartUp-Zeit (PowerOn delay). Diese Einstellung muss abhängig von der Art des Taktgenerators eingestellt werden, genaueres im jeweiligen Datenblatt.
|-
|'''SPIEN'''
|Hiermit kann die serielle [[AVR-ISP Programmierkabel|ISP-Programmierung]], welche die meisten Programmierkabel nutzen, deaktiviert werden. Dies sollte man lieber vermeiden, denn wenn dieser Programmiermodus deaktiviert wurde, kann nur noch der Parallel-Programmiermodus genutzt werden. Der Parallel-Programmiermodus benötigt jedoch ein spezielles Programmiergerät, das die wenigsten Bastler besitzen. ''Also Vorsicht!''
|-
|'''BODEN'''
|Über dieses Bit wird der '''Brown-out Detector''' aktiviert bzw. deaktiviert. Dies ist eine Überwachung der Betriebsspannung. Diese Überwachung soll dafür sorgen, dass bei Spannungseinbrüchen ein ordentlicher RESET durchgeführt wird. Dadurch wird verhindert, dass ein Controller in einen undefinierten Zustand gerät (hängen bleibt).
|-
|'''BOOTLEVEL'''
|Über dieses Bit kann die Spannung festgelegt werden, ab welcher der '''Brown-out Detector''' den Controller neu startet (also RESET ausführt).
|-
|'''BOOTRST'''
|Gewöhnlich startet ein Programm im Controller nach einem RESET ab Adresse 0. Durch dieses Fusebit kann der Controller jedoch veranlasst werden, nach einem Reset einen sogenannten Bootloader-Bereich auszuführen. Ein [[Bootloader]] kann genutzt werden, um Controller über andere Schnittstellen (z.B. RS232) zu programmieren.
|-
|'''BOOTSZ0, BOOTSZ1'''
|Der zuvor genannte Bootloaderbereich kann bei AVR-Controllern verschieden groß sein. Über diese beiden Bits können vier verschiedene Größen eingestellt werden. Siehe unter [[Bootloader]].
|-
|'''EESAVE'''
|Dieses Bit legt fest, ob beim Programmieren des Controllers (man nennt es auch brennen) immer das EEPROM gelöscht werden soll.
|-
|'''CKOPT'''
|Abhängig von den Einstellungen von CKSEL kann hier dir Oszillator-Verstärkung eingestellt werden. Genaueres im Datenblatt des jeweiligen Controllers.
|-
|'''WDTON'''
|Schaltet den WatchDog-Timer beim Booten ein/aus. Dies ist auch per Software möglich
|-
|'''RSTDISBL'''
|Durch dieses Bit kann man den RESET-Pin deaktivieren und dann als normalen I/O-Port nutzen. Aber Vorsicht! Da die RESET-Leitung beim Programmieren (Brennen) des Chips genutzt wird, kann man nach dessen Deaktivierung den Controller mit den üblichen [[AVR-ISP Programmierkabel|ISP-Adaptern]] nicht mehr programmieren. In diesem Fall könnte man zwar den Controlle noch mit speziellen Programmiergeräten im Parallelmodus programmieren, aber in der Praxis verfügen nur wenige Bastler über ein Programmiergerät, das dies leistet.
|-
|'''LB1, LB2'''
|Das sind die sogenannten Lockbits, mit denen sich das Auslesen des Flash- als auch EEPROM-Speichers verhindern läßt. Zwar können andere Anwender immer noch Daten lesen, allerdings handelt es sich dabei nicht mehr um den wirklichen Inhalt sondern lediglich um wirre Datenbytefolgen. Programmierer, die den erarbeiteten Code vor Raubkopierern schützen wollen, nutzen diese Lockbits. Das Programmieren ist auch bei gesetzen Lockbits noch möglich. Der Bootloader-Bereich wird nicht durch die Lockbits geschützt.
|-
|'''BLB01, BLB02'''
|Durch diese Bits kann der Code sogar vor dem Zugriff durch den Bootloader geschützt werden
|-
|'''BLB11, BLB12'''
|Diese Bits schützen den Bootloaderbereich selbst
|}

Wie man die Fusebits mit [[Bascom]] einstellt, wird im Beitrag [[Bascom - Erstes Programm in den AVR Controller übertragen]] erläutert.

''Autoren des Artikels: Frank, Luma''

==Siehe auch==
* [[Atmel]]
* [[AVR-Einstieg leicht gemacht]]
* [[Avr-gcc|avr-gcc]] - Leistungsfähiger AVR-Port des freien Compilers GCC
* [[WinAVR]] - Ein freies Werkzeugpaket auf Basis avr-gcc für die Windows-Platform, integriert unter anderem das [[Programmer's Notepad]]
* [[AVR_Assembler_Einf%C3%BChrung|AVR Assembler Einführung (AvrStudio)]]
* [[AVR-ISP Programmierkabel]] - Bauanleitung für die AVR Controller Programmierkabel
* [[RN-Control]] - Eines der beliebtestet AVR-Boards im Roboternetz
* [[RNBFRA-Board]] - Größeres Board mit zwei Atmel Controllern
* [[Bascom]] - Sehr gutes Basic-Entwicklungssystem
* [[Bascom - Erstes Programm in den AVR Controller übertragen]]
* [[On Chip Debugging]]
* [[Bootloader]]
* [[Timer]]
* [[TWI]] - I2C beim AVR

==Weblinks==
* [http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC Aktuelle AVR Vergleichstabelle]
* [http://www.atmel.com/dyn/products/devices.asp?family_id=607 Die Datenblätter zu Atmel Controllern]
* [https://mpg.dnsalias.com/~magerlu/rn-wiki/avrtimer_applet Java Applet Timer Berechnung]
* [http://www.roboternetz.de/phpBB2/dload.php?action=file&file_id=169 AvrTimer Windows Berechnungstool]
* [http://people.freenet.de/gjl/helferlein/avr-uart-rechner.html AVR-Baudraten-Rechner (JavaScript)]

[[Kategorie:Microcontroller]]
[[Kategorie:Grundlagen]]
[[Kategorie:Elektronik]]
[[Kategorie:Abkürzung|AVR]]