Mikrocontroller.net - Benutzerbeiträge [de]

AVR-GCC-Tutorial

2015-12-11T14:38:26Z

Kbuchegg: Ergänzung eines Codebeispiels

Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.

Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.

= Vorwort =

In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.

Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.

Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.

Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (nicht immer auf aktuellem Stand).

== Weiterführende Kapitel ==

Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].

;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''

;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''

;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''

;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''

;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''

;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''

;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''

;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''

= Benötigte Werkzeuge =

Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:

* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.

Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.

Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:

* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig.

:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].

* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).

* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].

* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].

= Was tun, wenn's nicht klappt? =

* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.

* Die [[AVR Checkliste]] durcharbeiten.

* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.

* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.

* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.

* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.

* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.

* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).

* Google oder yahoo befragen schadet nie.

* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.

* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.

* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.

= Erzeugen von Maschinencode =

Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z. B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z. B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:

* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z. B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z. B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen.

* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses).

* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.

Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.

= Einführungsbeispiel =

Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.

Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden.

Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.

Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.

<syntaxhighlight lang="c">
/* Alle Zeichen zwischen Schrägstrich-Stern
und Stern-Schrägstrich sind Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h> // (1)

int main (void) { // (2)

DDRB = 0xFF; // (3)
PORTB = 0x03; // (4)

while(1) { // (5)
/* "leere" Schleife*/ // (6)
} // (7)

/* wird nie erreicht */
return 0; // (8)
}
</syntaxhighlight>

# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein <code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein <code>\</code>.
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight>
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.

Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].

<pre>
D:\beispiel>dir

Verzeichnis von D:\beispiel

28.11.2006 22:53 <DIR> .
28.11.2006 22:53 <DIR> ..
28.11.2006 20:06 118 main.c
28.11.2006 20:03 16.810 Makefile
2 Datei(en) 16.928 Bytes
</pre>

Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist.
<pre>
D:\beispiel>make all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -
o obj/main.o

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
--output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex
</pre>

Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z. B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z. B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.

Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.

= Ganzzahlige Datentypen (Integer) =

Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.

Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight>

{| {{Tabelle}}
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''  
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenbehaftete int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −27 ⋯ 27−1 || <code>signed char</code>
|-
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −215 ⋯ 215−1 || <code>signed short</code>, <code>signed int</code>
|-
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −231 ⋯ 231−1 || <code>signed long</code>
|-
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −263 ⋯ 263−1 || <code>signed long long</code>
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenlose int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 28−1 || <code>unsigned char</code>
|-
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 216−1 || <code>unsigned short</code>, <code>unsigned int</code>
|-
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 232−1 || <code>unsigned long</code>
|-
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 264−1 || <code>unsigned long long</code>
|}

Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].

= Grundsätzlicher Programmaufbau eines µC-Programms =

Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in
welcher Programmiersprache das Programm geschrieben wird.

== Sequentieller Programmablauf ==

[[Image:Sequentielle Programme.gif|left]]
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".
{{Absatz}}

== Interruptgesteuerter Programmablauf ==

[[Image:Interrupt Programme.gif|left]]
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.
{{Absatz}}

= Zugriff auf Register =

Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die
Inhalte der Register sowohl auslesen als auch beschreiben.

Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.

Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.

Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:

<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Ist im Makefile der MCU-Typ z. B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.


Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z. B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:

<pre>
[...]
# MCU Type ("name") setzen:
MCU = atmega16
[...]

[...]
## Verwendung des Inhalts von MCU (hier atmega16) fuer die
## Compiler- und Assembler-Parameter
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)
[...]

[...]
## Aufruf des Compilers:
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@
[...]
</pre>

Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:

<syntaxhighlight lang="c">
// avr/io.h
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)
[...]
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
// [...]
#elif defined (__AVR_ATmega16__)
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:
# include <avr/iom16.h>
// [...]
#else
# if !defined(__COMPILING_AVR_LIBC__)
# warning "device type not defined"
# endif
#endif
</syntaxhighlight>

Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z. B. die des UART, ADC, SPI) analog.

== Schreiben in Register ==

Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref>

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main()
{
/* Setzt das Richtungsregister des Ports A auf 0xff
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */
DDRA = 0xff;

/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */
PORTA = 0x03;

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

while (1);
}
</syntaxhighlight>

Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].

Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z. B. DDRB = 0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.

== Verändern von Registerinhalten ==

Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen.

<syntaxhighlight lang="c">
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht
</syntaxhighlight>

Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
#define MEINBIT 2
...
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
</syntaxhighlight>

Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */
</syntaxhighlight>

Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen
</syntaxhighlight>

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.

Siehe auch:
* [[Bitmanipulation]]
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers

== Lesen aus Registern ==

Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>

uint8_t foo;

//...

int main(void)
{
/* kopiert den Status der Eingabepins an PortB
in die Variable foo: */
foo = PINB;
//...
}
</syntaxhighlight>

Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:

<syntaxhighlight lang="c">
#define MEINBIT0 0
#define MEINBIT2 2

uint8_t i;

extern test1();

// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist
i = PINA; // Inhalt in Arbeitsvariable
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)
// falls das Bit gesetzt war, hat i den Inhalt 1
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)?
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen
}
// verkürzt:
if ( ( PINA & 0x01 ) != 0 ) {
test1();
}
// nochmals verkürzt:
if ( PINA & 0x01 ) {
test1();
}
// mit definierter Bitnummer:
if ( PINA & ( 1 << MEINBIT0 ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5)
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)
if ( PINA & 0x05 ) {
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt
}
// mit definierten Bitnummern:
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt
test1();
}

// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist
i = PINA; // einlesen in temporäre Variable
i = i & 0x01; // maskieren von Bit 0
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist
test2();
}
// analog mit not-Operator
if ( !i ) {
test2();
}
// nochmals verkürzt:
if ( !( PINA & 0x01 ) ) {
test2();
}
</syntaxhighlight>

== Warten auf einen bestimmten Zustand ==

Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers).

Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */

#define WARTEPIN PINA
#define WARTEBIT PA2

// mit der avr-libc Funktion:
loop_until_bit_is_set(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// _nicht_ ungleich 0 (also 0) ist.
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}
...
</syntaxhighlight>

Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */
#define WARTEPIN PINB
#define WARTEBIT PB4

// avr-libc-Funktion:
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// gesetzt (1) ist
while ( WARTEPIN & (1<<WARTEBIT) ) {}
...
</syntaxhighlight>

Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers
* [[Bitmanipulation]]

== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==

Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.
<syntaxhighlight lang="c">
#include <avr/io.h>
...
uint16_t foo;

/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */
foo = ADC;
</syntaxhighlight>

Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:

<syntaxhighlight lang="c">
#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

...
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;

UBRRH = (uint8_t) (baud >> 8);
UBRRL = (uint8_t) baud;
...
</syntaxhighlight>

Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''.

Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z. B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann.

Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.

Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.

Das bedeutet für die Reihenfolge:
* Lesezugriff: Erst Low-Byte, dann High-Byte
* Schreibzugriff: Erst High-Byte, dann Low-Byte

Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.

Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!

Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!

In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z. B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.

Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.

Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.

ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt.

Im Umgang mit 16-Bit Registern siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8
* Datenblatt Abschnitt ''Accessing 16-bit Registers''

== IO-Register als Parameter und Variablen ==

Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <util/delay.h>

uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)
{
static uint8_t last_state = 0;

if (last_state == (*inputreg & (1<<inputbit)))
return 0; /* keine Änderung */

/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */
_delay_ms(20);

/* Zustand für nächsten Aufruf merken: */
last_state = *inputreg & (1<<inputbit);

/* und den entprellten Tastendruck zurückgeben: */
return *inputreg & (1<<inputbit);
}

/* Beispiel für einen Funktionsaufruf: */

void foo (void)
{
uint8_t i = key_pressed (&PINB, PB1);
}
</syntaxhighlight>

Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.

Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]

= Zugriff auf IO-Ports =

Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen
* bei Ausgängen deren Zustand festzulegen
* bei Eingängen deren Zustand zu erfassen

Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).

Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.

Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.

Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:

{| class="wikitable"
|-
! DDRx
| Datenrichtungsregister für Port'''x'''.
'''x''' entspricht '''A''', '''B''', ''' C''', '''D''' usw. (abhängig von der Anzahl der Ports des verwendeten AVR). Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.
|-
! PINx
| Eingangsadresse für Port'''x'''.
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.
|-
! PORTx
| Datenregister für Port'''x'''.
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).
|}

Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.

== Datenrichtung bestimmen ==

Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.

Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang
verwendet werden, muss das entsprechende Bit gelöscht sein.

Beispiel:
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen

+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

In C liest sich das dann so:

<syntaxhighlight lang="c">
// in io.h wird u.a. DDRB definiert:
#include <avr/io.h>

int main()
{
// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
// direkte Zuweisung - standardkonform */
DDRB = 0x1F; /*

// übersichtliche Alternative - Binärschreibweise, aber kein ISO-C
DDRB = 0b00011111;

// Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
// aber übersichtlicher und selbsterklärend:
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);
</syntaxhighlight>

Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:

<syntaxhighlight lang="c">
// Alle Pins des Ports B als Ausgang definieren:
DDRB = 0xff;
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~(1 << DDB0);
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~((1 << DDB3) | (1 << DDB4));
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
DDRB |= (1 << DDB0) | (1 << DDB3);
// Alle Pins auf Eingang:
DDRB = 0x00;
</syntaxhighlight>

== Vordefinierte Bitnummern für I/O-Register ==

Die Bitnummern (z. B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):

<syntaxhighlight lang="c">
...
/* PORTC */
#define PC7 7
#define PC6 6
#define PC5 5
#define PC4 4
#define PC3 3
#define PC2 2
#define PC1 1
#define PC0 0

/* DDRC */
#define DDC7 7
#define DDC6 6
#define DDC5 5
#define DDC4 4
#define DDC3 3
#define DDC2 2
#define DDC1 1
#define DDC0 0

/* PINC */
#define PINC7 7
#define PINC6 6
#define PINC5 5
#define PINC4 4
#define PINC3 3
#define PINC2 2
#define PINC1 1
#define PINC0 0
</syntaxhighlight>

== Digitale Signale ==

Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.

== Ausgänge ==
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.

Mit dem Befehl
<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = 0x04; /* besser PORTB=(1<<PB2) */

// übersichtliche Alternative - Binärschreibweise
PORTB = 0b00000100; /* direkte Zuweisung - übersichtlich */

</syntaxhighlight>
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).

Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */
/* vereinfacht durch Nutzung des |= Operators : */
PORTB |= (1<<PB2);

/* auch mehrere "gleichzeitig": */
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */
</syntaxhighlight>

"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */
</syntaxhighlight>
Siehe auch [[Bitmanipulation]]

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.

''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''

Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:
* zuerst die Bits im PORTx-Register setzen
* anschließend die Datenrichtung auf Ausgang stellen

Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:
* setze PORTx: interner Pull-Up aktiv
* setze DDRx: Ausgang ("high")

Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.

== Eingänge (Wie kommen Signale in den µC) ==

Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.

=== Signalkopplung ===

Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.

Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z. B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.

Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.

{| class="wikitable" style="text-align:center"
|+ '''Spannungstabelle''' (ca. Grenzwerte)
|
! Low || High
|-
! bei 5 V
| 1 V || 3,5 V
|-
! bei 3,3 V
| 0,66 V || 2,31 V
|-
! bei 1,8 V
| 0,36 V || 1,26 V
|}

Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.

{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}

Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>
...
uint8_t bPortD;
...
bPortD = PIND;
...
</syntaxhighlight>

Mit den C-Bitoperationen kann man den Status der Bits abfragen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */
if ( PINC & (1<<PINC1) ) {
/* Aktion */
}

/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */
if ( !(PINB & (1<<PINB2)) ) {
/* Aktion */
}
...
</syntaxhighlight>
Siehe auch [[Bitmanipulation#Bits_prüfen]]

=== Interne Pull-Up Widerstände ===

Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z. B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.

Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.

Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.

Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRD = 0x00; /* alle Pins von Port D als Eingang */
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */
...
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */
</syntaxhighlight>

=== Taster und Schalter ===

Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.

<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC">
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten.
</gallery>

Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z. B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.

==== Taster entprellen ====

Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]

= Warteschleifen (delay.h) =

Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:

* Warten im Sinn von Zeitvertrödeln
* Warten auf einen bestimmten Zustand an den I/O-Pins
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)
* Warten auf einen bestimmten Zählerstand (siehe Counter)

Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.

Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z. B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z. B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden.

Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.

Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...

Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.

== avr-libc Versionen bis 1.6 ==

Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z. B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */

/*
lange, variable Verzögerungszeit, Einheit in Millisekunden

Die maximale Zeit pro Funktionsaufruf ist begrenzt auf
262.14 ms / F_CPU in MHz (im Beispiel:
262.1 / 3.6864 = max. 71 ms)

Daher wird die kleine Warteschleife mehrfach aufgerufen,
um auf eine längere Wartezeit zu kommen. Die zusätzliche
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig
ungenau werden (macht hier vielleicht 2-3ms aus).
*/

void long_delay(uint16_t ms)
{
for(; ms>0; ms--) _delay_ms(1);
}

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) // Endlosschleife
{
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z. B. angeschlossene LED
long_delay(1000); // Eine Sekunde warten...
}

return 0;
}
</syntaxhighlight>

== avr-libc Versionen ab 1.7 ==

_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.

Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...
// funktioniert nicht mit Bibliotheken vor 1.6

}
return 0;
}
</syntaxhighlight>

Trick zur Übergabe einer Variablen an _delay_ms():
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

void sleep ( uint8_t ms )
{
for(; ms > 0; ms--) _delay_ms(1);
}

int main( void )
{
int x = 0; // Variable als Wartezeit erstellen
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
sleep(x);
x++;
}
return 0;
}
</syntaxhighlight>

Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]

= Programmieren mit Interrupts =

<div style="float:right; margin:2em;">
[[Image:Interrupt Programme.gif]]
</div>
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich
die Programmierung unter Zuhilfenahme der Interrupts des AVR.

Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).

Um Interrupts verarbeiten zu können, ist folgendes zu beachten:

* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).

Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.

Siehe auch

* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]
* Artikel [[Interrupt]]
* Artikel [[Multitasking]]
{{Clear}}

== Anforderungen an Interrupt-Routinen ==

Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:

* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)
* Keine langen Programmschleifen.
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.

Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.

(*)
Hinweis:
Es gibt allerdings die seltene Situation, dass man gerade eingelesene
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!

== Interrupt-Quellen ==

Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.

* Reset
* Externer Interrupt 0
* Externer Interrupt 1
* Timer/Counter 1 Capture Ereignis
* Timer/Counter 1 Compare Match
* Timer/Counter 1 Überlauf
* Timer/Counter 0 Überlauf
* UART Zeichen empfangen
* UART Datenregister leer
* UART Zeichen gesendet
* Analoger Komparator

Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").

== Register ==

Der AT90S2313 verfügt über 2 Register die mit den
Interrupts zusammenhängen.

{| class="wikitable"
|-
| '''GIMSK'''
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INT1''' (External '''Int'''errupt Request '''1''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

'''INT0''' (External '''Int'''errupt Request '''0''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

|-
| '''GIFR'''
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INTF1''' (External '''Int'''errupt Flag '''1''')
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.

'''INTF0''' (External '''Int'''errupt Flag '''0''')
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.
|-
| '''MCUCR'''
| '''MCU''' '''C'''ontrol '''R'''egister.

Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''
|-
! R/W
| R || R || R/W || R/W || R/W || R/W || R/W || R/W
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0

|}

'''SE''' ('''S'''leep '''E'''nable)
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.

'''SM''' ('''S'''leep '''M'''ode)
:Dieses Bit bestimmt über den Schlafmodus.
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")

'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC11 || ISC10 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT1''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.
|}

'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC01 || ISC00 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT0''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.
|}

|}

== Allgemeines über die Interrupt-Abarbeitung ==

Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist.



== Interrupts mit avr-gcc ==



Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').

<syntaxhighlight lang="c">
// fuer sei(), cli() und ISR():
#include <avr/interrupt.h>
</syntaxhighlight>

Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.

<syntaxhighlight lang="c">
sei();
</syntaxhighlight>

Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.

<syntaxhighlight lang="c">
cli();
</syntaxhighlight>

Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>

//...

void NichtUnterbrechenBitte(void)
{
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister

tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern
cli(); // Interrupts global deaktivieren

/* hier "unterbrechnungsfreier" Code */

/* Beispiel Anfang
JTAG-Interface eines ATmega16 per Software deaktivieren
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229):
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */

MCUCSR |= (1<<JTD);
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information

/* Beispiel Ende */

SREG = tmp_sreg; // Status-Register wieder herstellen
// somit auch das I-Flag auf gesicherten Zustand setzen
}

void NichtSoGut(void)
{
cli();

/* hier "unterbrechnungsfreier" Code */

sei();
}

int main(void)
{
//...

cli();
// Interrupts global deaktiviert

NichtUnterbrechenBitte();
// auch nach Aufruf der Funktion deaktiviert

sei();
// Interrupts global aktiviert

NichtUnterbrechenBitte();
// weiterhin aktiviert
//...

/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */
cli();
// Interrupts jetzt global deaktiviert

NichtSoGut();
// nach Aufruf der Funktion sind Interrupts global aktiviert
// dies ist mglw. ungewollt!
//...

}
</syntaxhighlight>


Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.

=== ISR ===

(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
//...
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */
{
/* Interrupt Code */
}
</syntaxhighlight>

Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.

Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.

<syntaxhighlight lang="c">
//...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */

/* avr/iom8.h - definitions for ATmega8 */
//...

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect _VECTOR(1)
#define SIG_INTERRUPT0 _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect _VECTOR(2)
#define SIG_INTERRUPT1 _VECTOR(2)

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)

/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect _VECTOR(4)
#define SIG_OVERFLOW2 _VECTOR(4)

/* Timer/Counter1 Capture Event */
#define TIMER1_CAPT_vect _VECTOR(5)
#define SIG_INPUT_CAPTURE1 _VECTOR(5)

/* Timer/Counter1 Compare Match A */
#define TIMER1_COMPA_vect _VECTOR(6)
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)

/* Timer/Counter1 Compare Match B */
#define TIMER1_COMPB_vect _VECTOR(7)
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)

//...
</syntaxhighlight>


Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
/* veraltet: #include <avr/signal.h> */

ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */
{
/* Interrupt Code */
}

ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
/* Interrupt Code */
}

ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */
{
/* Interrupt Code */
}

// und so weiter und so fort...
</syntaxhighlight>

Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]).

Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.

Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.

Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.

=== Unterbrechbare Interruptroutinen ===

"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */
{
/* Interrupt-Code */
}
</syntaxhighlight>

Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z. B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden – auch XXX-Interrupts.

Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.

Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR (XXX)
{
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen

<<Deaktiviere die XXX-IRQ>>

// Erlaube alle Interrupts (ausser XXX)
sei();

//... Code ...

// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos
// aktivieren zu koennen
cli();

<<Aktiviere die XXX-IRQ>>
}
</syntaxhighlight>
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.

Siehe auch: Hinweise in [[AVR-GCC]]

siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

== Datenaustausch mit Interrupt-Routinen ==

Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.

Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdint.h>
//...

// Schwellwerte
// Entprellung:
#define CNTDEBOUNCE 10
// "lange gedrueckt:"
#define CNTREPEAT 200

// hier z. B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt
#define KEY_PIN PINA
#define KEY_PINNO PA2

// beachte: volatile!
volatile uint8_t gKeyCounter;

// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt
ISR(TIMER1_COMPA_vect)
{
// hier wird gKeyCounter veraendert. Die übrigen
// Programmteile müssen diese Aenderung "sehen":
// volatile -> aktuellen Wert immer in den Speicher schreiben
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
}
else {
gKeyCounter = 0;
}
}

//...

int main(void)
{
//...
/* hier: Initialisierung der Ports und des Timer-Interrupts */
//...
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der
// ISR geschriebene Wert bekannt sein:
// volatile -> aktuellen Wert immer aus dem Speicher lesen
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"
if (gKeyCounter == CNTREPEAT) {
/* hier: Code fuer "Taste lange gedrueckt" */
}
else {
/* hier: Code fuer "Taste kurz gedrueckt" */
}
}
//...
}
</syntaxhighlight>

Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:

<syntaxhighlight lang="c">
//...
ISR(TIMER1_COMPA_vect)
{
uint8_t tmp_kc;

tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (tmp_kc < CNTREPEAT) {
tmp_kc++;
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc; // Zurueckschreiben
}
//...
</syntaxhighlight>

Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
876: ca 99 sbic 0x19, 2 ; 25
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24>
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
87a: 80 91 2a 03 lds r24, 0x032A
87e: 88 3c cpi r24, 0xC8 ; 200
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28>
882: 80 91 2a 03 lds r24, 0x032A
886: 8f 5f subi r24, 0xFF ; 255
888: 80 93 2a 03 sts 0x032A, r24
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28>
}
else {
gKeyCounter = 0;
88e: 10 92 2a 03 sts 0x032A, r1
892: 8f 91 pop r24
894: 0f 90 pop r0
896: 0f be out 0x3f, r0 ; 63
898: 0f 90 pop r0
89a: 1f 90 pop r1
89c: 18 95 reti
</pre>

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
uint8_t tmp_kc;

tmp_kc = gKeyCounter;
876: 80 91 2a 03 lds r24, 0x032A

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
87a: ca 9b sbis 0x19, 2 ; 25
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18>
87e: 80 e0 ldi r24, 0x00 ; 0
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e>
if (tmp_kc < CNTREPEAT) {
882: 88 3c cpi r24, 0xC8 ; 200
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e>
tmp_kc++;
886: 8f 5f subi r24, 0xFF ; 255
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc;
888: 80 93 2a 03 sts 0x032A, r24
88c: 8f 91 pop r24
88e: 0f 90 pop r0
890: 0f be out 0x3f, r0 ; 63
892: 0f 90 pop r0
894: 1f 90 pop r1
896: 18 95 reti
</pre>

=== volatile und Pointer ===

Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.

<syntaxhighlight lang="c">
volatile uint8_t *a; // das Ziel von a ist volatile

uint8_t *volatile a; // a selbst ist volatile
</syntaxhighlight>

Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.

=== Variablen größer 1 Byte ===

Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:

<syntaxhighlight lang="c">
//...
volatile uint16_t gMyCounter16bit;
//...
ISR(...)
{
//...
gMyCounter16Bit++;
//...
}

int main(void)
{
uint16_t tmpCnt;
//...
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.
tmpCnt = gMyCounter16bit;

// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"
// bleiben konsistent
cli(); // Interrupts deaktivieren
tmpCnt = gMyCounter16Bit;
sei(); // wieder aktivieren

// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten
uint8_t sreg_tmp;
sreg_tmp = SREG; /* Sichern */
cli()
tmpCnt = gMyCounter16Bit;
SREG = sreg_tmp; /* Wiederherstellen */

// oder: mehrfach lesen, bis man konsistente Daten hat
uint16_t count1 = gMyCounter16Bit;
uint16_t count2 = gMyCounter16Bit;
while (count1 != count2) {
count1 = count2;
count2 = gMyCounter16Bit;
}
tmpCnt = count1;
//...
}
</syntaxhighlight>

Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.
<syntaxhighlight lang="c">
//...
#include <util/atomic.h>
//...

// analog zu cli, Zugriff, sei:
ATOMIC_BLOCK(ATOMIC_FORCEON) {
tmpCnt = gMyCounter16Bit;
}

// oder:

// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
tmpCnt = gMyCounter16Bit;
}

//...
</syntaxhighlight>

* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]

== Interrupt-Routinen und Registerzugriffe ==

Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können.

Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main(void)
{
//...
PORTA |= (1<<PA0);

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
//...
}
</syntaxhighlight>

Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:

<div class="code"><pre>
...
PORTA |= (1<<PA0);
d2: d8 9a sbi 0x1b, 0 ; 27 (a)

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
d4: 8b b3 in r24, 0x1b ; 27 (b)
d6: 8c 61 ori r24, 0x1C ; 28 (c)
d8: 8b bb out 0x1b, r24 ; 27 (d)
...
</pre></div>

Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z. B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben.

Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt.

Lösungsmöglichkeiten:
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)

== Interruptflags löschen ==

Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben.

Hinweis: 
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten. 
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).

== Was macht das Hauptprogramm? ==

Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den meisten Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.

Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals

= Sleep-Modes =

AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.

;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z. B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).

Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
...

while (1) {
...
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

// Code hier wird erst nach Auftreten eines entsprechenden
// "Aufwach-Interrupts" verarbeitet
...
}
}
</syntaxhighlight>

In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():

<syntaxhighlight lang="c">
#include <avr/io.h>
...
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren
SMCR = (3<<SM0) | (1<<SE);
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h
...
</syntaxhighlight>

== Sleep Modi ==
Zu beachten ist, dass unterschiedliche Prozessoren aus der AVR Familie unterschiedliche Sleep-Modi unterstützen oder nicht unterstützen. Auskunft über die tatsächlichen Gegebenheiten gibt, wie immer, das zum Prozessor gehörende Datenblatt. Die unterschiedlichen Modi unterscheiden sich dadurch, welche Bereiche des Prozessors abgeschaltet werden. Damit korrespondiert unmittelbar welche Möglichkeiten es gibt, den Prozessor aus den jeweiligen Sleep Modus wieder aufzuwecken.

;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.

;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann. Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.

;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator) gestoppt. Geweckt werden kann die CPU durch einen externen Level Interrupt, TWI, Watchdog, Brown-Out-Reset

;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.

;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators (also einer externen Taktquelle). Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus ist eine kürzere Aufwachzeit.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.

= Zeiger =
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.

Siehe auch: [[Zeiger]]

= Speicherzugriffe =

Atmel AVR-Controller verfügen typisch über drei Speicher:

* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.

* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.

* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z. B. Kalibrierungswerte von Sensoren abgelegt.

Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.

Siehe auch:
* [[Binäre Daten zum Programm hinzufügen]]
== RAM ==

Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.

Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.

Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).

malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.

Beispiel zur Verwendung von malloc():
<syntaxhighlight lang="c">
#include <stdlib.h>

void foo(void) {
// neuen speicherbereich anlegen,
// platz für 10 uint16
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));

// darauf zugreifen, als wärs ein gewohnter Buffer
pBuffer[2] = 5;

// Speicher (unbedingt!) wieder freigeben
free(pBuffer);
}
</syntaxhighlight>

Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.

siehe auch:
* http://www.nongnu.org/avr-libc/user-manual/malloc.html

== Flash mit PROGMEM und pgm_read ==

→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]

Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELMP.

Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:
<syntaxhighlight lang="c">
const int value __attribute__((progmem)) = 1;
</syntaxhighlight>

Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus dem RAM gelesen und nicht aus dem Flash!

Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

const int value PROGMEM = 1;
</syntaxhighlight>

<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.

=== Integer und float ===

Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref>

:{| {{Tabelle}}
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus dem Header <tt>avr/pgmspace.h</tt> der avr-libc
|-
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes
|-
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1
|-
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2
|-
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4
|-
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4
|}

Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.

;Beispiele:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Byte */
const uint8_t aByte PROGMEM = 123;

/* int-Array */
const int anArray[] PROGMEM = { 18, 3 ,70 };

void foo (void)
{
/* Zeiger */
static const uint8_t* const aPointer PROGMEM = &aByte;

uint8_t a = pgm_read_byte (&aByte);
int a2 = (int) pgm_read_word (&anArray[2]);
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);
}
</syntaxhighlight>

=== Blöcke ===

In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.

=== Strings ===

Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

size_t my_string_length (const char* addr)
{
size_t length = 0;

while (pgm_read_byte (addr++))
{
len++;
}
return length;
}
</syntaxhighlight>

Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Liefert true zurück, wenn string_im_ram gleich "Hallo Welt" ist. */
int foo (const char* string_im_ram)
{
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));
}
</syntaxhighlight>

Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.

; Array aus Strings:

Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:

# Zuerst die einzelnen Elemente des Arrays und
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.

Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char str1[] PROGMEM = "Hund";
static const char str2[] PROGMEM = "Katze";
static const char str3[] PROGMEM = "Maus";

const char * const array[] PROGMEM =
{
str1, str2, str3
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Lese die Adresse des i-ten Strings aus array[]
const char *parray = (const char*) pgm_read_word (&array[i]);

// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM
strcpy_P (buf, parray);
}
</syntaxhighlight>

Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.

Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref>

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")
const char array[][6] PROGMEM =
{
"Hund", "Katze", "Maus"
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM
strcpy_P (buf, array[i]);
}
</syntaxhighlight>

Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]

=== Warum so kompliziert? ===

Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.

Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.

Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.

Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities

=== Variablenzugriff >64kB ===

Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Um Flashzugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:

* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc, wie im folgenden beschrieben.

Unverständlicherweise gibt es in der AVR-Libc keine Funktion, um 32-Bit Pointer zu erhalten. Hier schafft ein eigenes GNU-C99 Makro Abhilfe:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/pgmspace.h>

//====================================================================
// Macro to access strings defined in PROGMEM above 64kB
//--------------------------------------------------------------------
#define FAR(var) \
({ uint_farptr_t tmp; \
__asm__ ( \
"ldi %A0, lo8(%1)" "\n\t" \
"ldi %B0, hi8(%1)" "\n\t" \
"ldi %C0, hh8(%1)" \
: "=d" (tmp) \
: "i" (&(var))); \
tmp; \
})
//-------------------------------------------------------------------

//===================================================================
// Define a section above 64kiB (FAR_SECTION)
// and add the required linker argument below
// -Wl,--section-start=.far_section=0x10000
//--------------------------------------------------------------------
#define FAR_SECTION __attribute__((__section__(".far_section")))
//--------------------------------------------------------------------

//====================================================================
// Just a Sample
//--------------------------------------------------------------------

const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};

int main(void)
{
char MyChar;
DDRC = 0xFF;
do
{
MyChar = pgm_read_byte_far(FAR(MyBmp64));
PORTC = MyChar;
}
while(MyChar);
}
</syntaxhighlight>

D.h. man muss
* Das Makro <tt>FAR</tt> im Quellcode einfügen
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen
* Die Variablen mit dieser Section kennzeichnen
* Dem Linker mittels Kommandozeilenoption die Startadrese dieser Section mitteilen

Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich.

<syntaxhighlight lang="c">
int n=3;
MyChar = pgm_read_byte_far(FAR(MyBmp64)+n);
</syntaxhighlight>

== Flash mit __flash und Embedded-C ==

Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.

GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.

<syntaxhighlight lang="c">
static const __flash int value = 10;

int get_value (void)
{
return value;
}
</syntaxhighlight>

# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.

Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse

<syntaxhighlight lang="c">
// val ist eine Variable im Flash
const __flash int val = 42;

// pval liegt auch im Flash und enthält die Adresse von val
const __flash int* const __flash pval = &val;

char get_val (void)
{
// liest den Wert von val über die in pval abgelegte Adresse
return *pval;
}
</syntaxhighlight>

=== Blöcke ===

Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// buf wird auf dem Stack angelegt
data_t buf;

// Kopiere Daten vom Flash nach buf ins RAM
memcpy_P (&buf, pdata, sizeof (data_t));

// Sende die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:

<syntaxhighlight lang="c">
#include <stdlib.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt
const data_t buf = *pdata;

// Verwendet die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

=== Strings ===

Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

#define FSTR(X) ((const __flash char[]) { X } )

const __flash char * const __flash array[] =
{
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")
};

size_t get_len (uint8_t tier)
{
return strlen_P (array[tier]);
}
</syntaxhighlight>

Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.

Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:

<syntaxhighlight lang="c">
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"
const __flash char array[][6] =
{
"Hund", "Katze", "Maus"
};
</syntaxhighlight>

Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:

<syntaxhighlight lang="c">
static const __flash char strHund[] = "Hund";
static const __flash char strKatze[] = "Katze";
static const __flash char strMaus[] = "Maus";

const __flash char * const __flash array[] =
{
strHund, strKatze, strMaus
};
</syntaxhighlight>

=== Casts ===

Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>:

<syntaxhighlight lang="c">
#include <stdbool.h>

char read_char (const char *address, bool data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
</syntaxhighlight>

Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.

=== Jenseits von __flash ===

Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:

; <tt>__flash</tt>''N'': Mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist. Dies wird in Binutils noch nicht unterstützt<ref>[http://sourceware.org/PR14406 Binutils PR14406]: Support .progmem<N>.data sections to work with GCC's [http://gcc.gnu.org/PR49868 PR49868].</ref> (Stand Binutils 2.24) Die Unterstützung kann durch ein eigenes Linker-Skript erreicht werden, welches diese Sections wie vom Compiler erwartet lokatiert.
; <tt>__memx</tt>: Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:

:{|
|-
|<syntaxhighlight lang="c">
const __memx int a_flash = 42;
const int a_ram = 100;

static int get_a (const __memx int* pa)
{
return *pa;
}

int main (void)
{
return get_a (&a_flash) + get_a (&a_ram);
}</syntaxhighlight>
|}Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob aus dem RAM oder aus dem Flash gelesen werden soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik.

=== __flash, progmem und Portierbarkeit ===

Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.

Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.

Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.
<syntaxhighlight lang="c">
static const __flash char x[] = { 'A', 'V', 'R' };

char foo (void)
{
return x[2];
}
</syntaxhighlight>
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.

==== progmem → __flash ====

Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.

Eine Portierung wird man in zwei Schritten vornehmen:

;1. Definitionen von Flash-Variablen werden angepasst:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char hund[] PROGMEM = "Hund";
static const char katze[] PROGMEM = "Katze";
static const char maus[] PROGMEM = "Maus";

const char * const tier[] PROGMEM =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
static const __flash char hund[] = "Hund";
static const __flash char katze[] = "Katze";
static const __flash char maus[] = "Maus";

const __flash char * const __flash tier[] =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.

Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt

; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

extern const char *tier[];

char first_letter (uint8_t i)
{
const char* ptier = (const char*) pgm_read_word (&tier[i]);
return (char) pgm_read_byte (&ptier[0]);
}
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
#include <stdint.h>

extern const __flash char * const __flash tier[];

char first_letter (uint8_t i)
{
return tier[i][0];
}
</syntaxhighlight>
|}

== Dateien direkt im Flash einbinden ==

Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.

* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]

Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.

* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden

== Flash in der Anwendung schreiben ==

Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.

Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.

Siehe auch:
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]

== EEPROM ==

Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.

Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.

Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.

Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle.

Bei geschickter Programmierung (z. B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.

Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).

Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl.

=== EEMEM ===
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:

<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/eeprom.h>

/* Byte */
uint8_t eeFooByte EEMEM = 123;

/* Wort */
uint16_t eeFooWord EEMEM = 12345;

/* float */
float eeFooFloat EEMEM;

/* Byte-Array */
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };

/* 16-bit unsigned short feld */
uint16_t eeFooWordArray1[4] EEMEM;
</syntaxhighlight>

Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.

Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.

=== Bytes lesen/schreiben ===

Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:

<syntaxhighlight lang="c">
#define EEPROM_DEF 0xFF

void eeprom_example (void)
{
uint8_t myByte;

// myByte lesen (Wert = 123)
myByte = eeprom_read_byte (&eeFooByte);

// der Wert 99 wird im EEPROM an die Adresse der
// Variablen eeFooByte geschrieben
myByte = 99;
eeprom_write_byte(&eeFooByte, myByte); // schreiben

myByte = eeprom_read_byte (&eeFooByteArray1[1]);
// myByte hat nun den Wert 3

// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-
// zugriff, da die Werte gleich sind.
eeprom_update_byte(&eeFooByte, myByte);

// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE
// deaktiviert ist (unprogrammed/1)
//
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.

uint8_t fooByteDefault = 222;
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)
{
myByte = fooByteDefault;
}
}
</syntaxhighlight>

=== Wort lesen/schreiben ===

Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:

<syntaxhighlight lang="c">
// lesen
uint16_t myWord = eeprom_read_word (&eeFooWord);

// schreiben
eeprom_write_word (&eeFooWord, 2222);
</syntaxhighlight>

=== Block lesen/schreiben ===

Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.
<syntaxhighlight lang="c">
uint8_t myByteBuffer[3];
uint16_t myWordBuffer[4];

void eeprom_block_example (void)
{
/* Datenblock aus EEPROM lesen */

/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse
in das RAM-Array myByteBuffer */
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);

/* dito mit etwas Absicherung betr. der Länge */
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));

/* und nun mit 16-Bit Array */
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));

/* Datenblock in EEPROM schreiben */
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));
}
</syntaxhighlight>

=== Fließkommawerte lesen/schreiben ===

In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

float eeFloat EEMEM = 12.34f;

float void eeprom_float_example(float value)
{
/* float in EEPROM schreiben */
eeprom_write_float(&eeFloat, value);

/* float aus EEPROM lesen */
return eeprom_read_float(&eeFloat);
}</syntaxhighlight>

=== EEPROM-Speicherabbild in .eep-Datei ===

Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden.

Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].

Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.

Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen. Das geht natürlich nur, wenn 0xFF selbst nicht als Datenwert vorkommen kann.
<syntaxhighlight lang="c">
#define DUTY_CYCLE_DEFAULT 0x80

uint8_t eeDutyCycle EEMEM; // Platzhalter für EEPROM
uint8_t DutyCycle; // die echte Variable

int main(void)
{
DutyCycle = eeprom_read_byte( &eeDutyCycle );
if( DutyCycle == 0xFF ) // das allererste mal. Im EEPROM steht noch kein gültiger Wert
{
DutyCycle = DUTY_CYCLE_DEFAULT;
eeprom_writeByte( &eeDutyCycle, DutyCycle );
}

...
</syntaxhighlight>

=== Direkter Zugriff auf EEPROM-Adressen ===

Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende Funktionen hilfreich, um sich die Typecasts zu ersparen:

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

// Byte aus dem EEPROM lesen
uint8_t EEPReadByte(uint16_t addr)
{
return eeprom_read_byte((uint8_t *)addr);
}

// Byte in das EEPROM schreiben
void EEPWriteByte(uint16_t addr, uint8_t val)
{
eeprom_write_byte((uint8_t *)addr, val);
}
</syntaxhighlight>

oder als Makro:

<syntaxhighlight lang="c">
#define EEPReadByte(addr) eeprom_read_byte((uint8_t *)addr)
#define EEPWriteByte(addr, val) eeprom_write_byte((uint8_t *)addr, val)
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="c">
EEPWriteByte(0x20, 128); // Byte an die Adresse 0x20 schreiben
...
Val=EEPReadByte(0x20); // EEPROM-Wert von Adresse 0x20 lesen
</syntaxhighlight>

=== Was steckt dahinter? - EEPROM-Register ===
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.
;EECR: Ist das Kontrollregister für das EEPROM

Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:

:{| class="wikitable" style="text-align:center"
|+ '''Aufbau des EECR-Registers'''
|-
!Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE
|-
! Read/Write
| R || R || R || R || R/W || R/W || R/W || R/W
|-
!Init Value
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''Bedeutung der Bits'''

;Bit 4-7: nicht belegt

;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.

;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.

;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:
:# EEPROM-Bereitschaft abwarten (EEWE=0)
:# Adresse übergeben an EEAR
:# Daten übergeben an EEDR
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist

;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:
:# Bereitschaft zum Lesen prüfen (EEWE=0)
:# Adresse übergeben an EEAR
:# Lesezyklus auslösen mit EERE = 1
:# Warten, bis Lesevorgang abgeschlossen EERE = 0
:# Daten abholen aus EEDR

= Die Nutzung von sprintf und printf =

Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.

Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.

<syntaxhighlight lang="c">
#include <stdio.h>
#include <stdint.h>

// ...
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)
// ...

uint16_t counter;

// Ausgabe eines unsigned Integerwertes
void uart_puti( uint16_t value )
{
uint8_t puffer[20];

sprintf( puffer, "Zählerstand: %u", value );
uart_puts( puffer );
}

int main()
{
counter = 5;

uart_puti( counter );
uart_puti( 42 );
}
</syntaxhighlight>

Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z. B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdio.h>

void uart_init(void);

// a. Deklaration der primitiven Ausgabefunktion
int uart_putchar(char c, FILE *stream);

// b. Umleiten der Standardausgabe stdout (Teil 1)
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );

// c. Definition der Ausgabefunktion
int uart_putchar( char c, FILE *stream )
{
if( c == '\n' )
uart_putchar( '\r', stream );

loop_until_bit_is_set( UCSRA, UDRE );
UDR = c;
return 0;
}

void uart_init(void)
{
/* hier µC spezifischen Code zur Initialisierung */
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */

// Beispiel:
//
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz
// 9600 Baud 8N1

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
}

int main(void)
{
int16_t antwort = 42;
uart_init();

// b. Umleiten der Standardausgabe stdout (Teil 2)
stdout = &mystdout;

// Anwendung
printf( "Die Antwort ist %d.\n", antwort );
return 0;
}

// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74
// + Ergänzungen
</syntaxhighlight>

Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.

= Anmerkungen =
<references/>

= TODO =
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR
* "naked"-Funktionen

[[Kategorie:avr-gcc Tutorial| ]]

AVR-GCC-Tutorial

2015-12-11T14:31:23Z

Kbuchegg: /* Was steckt dahinter? - EEPROM-Register */

Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.

Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.

= Vorwort =

In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.

Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.

Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.

Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (nicht immer auf aktuellem Stand).

== Weiterführende Kapitel ==

Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].

;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''

;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''

;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''

;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''

;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''

;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''

;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''

;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''

= Benötigte Werkzeuge =

Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:

* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.

Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.

Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:

* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig.

:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].

* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).

* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].

* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].

= Was tun, wenn's nicht klappt? =

* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.

* Die [[AVR Checkliste]] durcharbeiten.

* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.

* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.

* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.

* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.

* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.

* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).

* Google oder yahoo befragen schadet nie.

* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.

* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.

* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.

= Erzeugen von Maschinencode =

Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z. B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z. B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:

* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z. B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z. B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen.

* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses).

* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.

Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.

= Einführungsbeispiel =

Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.

Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden.

Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.

Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.

<syntaxhighlight lang="c">
/* Alle Zeichen zwischen Schrägstrich-Stern
und Stern-Schrägstrich sind Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h> // (1)

int main (void) { // (2)

DDRB = 0xFF; // (3)
PORTB = 0x03; // (4)

while(1) { // (5)
/* "leere" Schleife*/ // (6)
} // (7)

/* wird nie erreicht */
return 0; // (8)
}
</syntaxhighlight>

# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein <code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein <code>\</code>.
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight>
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.

Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].

<pre>
D:\beispiel>dir

Verzeichnis von D:\beispiel

28.11.2006 22:53 <DIR> .
28.11.2006 22:53 <DIR> ..
28.11.2006 20:06 118 main.c
28.11.2006 20:03 16.810 Makefile
2 Datei(en) 16.928 Bytes
</pre>

Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist.
<pre>
D:\beispiel>make all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -
o obj/main.o

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
--output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex
</pre>

Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z. B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z. B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.

Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.

= Ganzzahlige Datentypen (Integer) =

Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.

Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight>

{| {{Tabelle}}
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''  
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenbehaftete int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −27 ⋯ 27−1 || <code>signed char</code>
|-
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −215 ⋯ 215−1 || <code>signed short</code>, <code>signed int</code>
|-
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −231 ⋯ 231−1 || <code>signed long</code>
|-
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −263 ⋯ 263−1 || <code>signed long long</code>
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenlose int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 28−1 || <code>unsigned char</code>
|-
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 216−1 || <code>unsigned short</code>, <code>unsigned int</code>
|-
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 232−1 || <code>unsigned long</code>
|-
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 264−1 || <code>unsigned long long</code>
|}

Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].

= Grundsätzlicher Programmaufbau eines µC-Programms =

Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in
welcher Programmiersprache das Programm geschrieben wird.

== Sequentieller Programmablauf ==

[[Image:Sequentielle Programme.gif|left]]
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".
{{Absatz}}

== Interruptgesteuerter Programmablauf ==

[[Image:Interrupt Programme.gif|left]]
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.
{{Absatz}}

= Zugriff auf Register =

Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die
Inhalte der Register sowohl auslesen als auch beschreiben.

Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.

Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.

Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:

<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Ist im Makefile der MCU-Typ z. B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.


Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z. B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:

<pre>
[...]
# MCU Type ("name") setzen:
MCU = atmega16
[...]

[...]
## Verwendung des Inhalts von MCU (hier atmega16) fuer die
## Compiler- und Assembler-Parameter
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)
[...]

[...]
## Aufruf des Compilers:
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@
[...]
</pre>

Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:

<syntaxhighlight lang="c">
// avr/io.h
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)
[...]
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
// [...]
#elif defined (__AVR_ATmega16__)
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:
# include <avr/iom16.h>
// [...]
#else
# if !defined(__COMPILING_AVR_LIBC__)
# warning "device type not defined"
# endif
#endif
</syntaxhighlight>

Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z. B. die des UART, ADC, SPI) analog.

== Schreiben in Register ==

Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref>

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main()
{
/* Setzt das Richtungsregister des Ports A auf 0xff
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */
DDRA = 0xff;

/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */
PORTA = 0x03;

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

while (1);
}
</syntaxhighlight>

Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].

Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z. B. DDRB = 0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.

== Verändern von Registerinhalten ==

Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen.

<syntaxhighlight lang="c">
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht
</syntaxhighlight>

Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
#define MEINBIT 2
...
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
</syntaxhighlight>

Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */
</syntaxhighlight>

Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen
</syntaxhighlight>

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.

Siehe auch:
* [[Bitmanipulation]]
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers

== Lesen aus Registern ==

Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>

uint8_t foo;

//...

int main(void)
{
/* kopiert den Status der Eingabepins an PortB
in die Variable foo: */
foo = PINB;
//...
}
</syntaxhighlight>

Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:

<syntaxhighlight lang="c">
#define MEINBIT0 0
#define MEINBIT2 2

uint8_t i;

extern test1();

// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist
i = PINA; // Inhalt in Arbeitsvariable
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)
// falls das Bit gesetzt war, hat i den Inhalt 1
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)?
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen
}
// verkürzt:
if ( ( PINA & 0x01 ) != 0 ) {
test1();
}
// nochmals verkürzt:
if ( PINA & 0x01 ) {
test1();
}
// mit definierter Bitnummer:
if ( PINA & ( 1 << MEINBIT0 ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5)
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)
if ( PINA & 0x05 ) {
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt
}
// mit definierten Bitnummern:
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt
test1();
}

// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist
i = PINA; // einlesen in temporäre Variable
i = i & 0x01; // maskieren von Bit 0
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist
test2();
}
// analog mit not-Operator
if ( !i ) {
test2();
}
// nochmals verkürzt:
if ( !( PINA & 0x01 ) ) {
test2();
}
</syntaxhighlight>

== Warten auf einen bestimmten Zustand ==

Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers).

Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */

#define WARTEPIN PINA
#define WARTEBIT PA2

// mit der avr-libc Funktion:
loop_until_bit_is_set(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// _nicht_ ungleich 0 (also 0) ist.
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}
...
</syntaxhighlight>

Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */
#define WARTEPIN PINB
#define WARTEBIT PB4

// avr-libc-Funktion:
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// gesetzt (1) ist
while ( WARTEPIN & (1<<WARTEBIT) ) {}
...
</syntaxhighlight>

Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers
* [[Bitmanipulation]]

== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==

Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.
<syntaxhighlight lang="c">
#include <avr/io.h>
...
uint16_t foo;

/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */
foo = ADC;
</syntaxhighlight>

Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:

<syntaxhighlight lang="c">
#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

...
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;

UBRRH = (uint8_t) (baud >> 8);
UBRRL = (uint8_t) baud;
...
</syntaxhighlight>

Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''.

Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z. B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann.

Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.

Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.

Das bedeutet für die Reihenfolge:
* Lesezugriff: Erst Low-Byte, dann High-Byte
* Schreibzugriff: Erst High-Byte, dann Low-Byte

Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.

Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!

Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!

In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z. B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.

Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.

Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.

ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt.

Im Umgang mit 16-Bit Registern siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8
* Datenblatt Abschnitt ''Accessing 16-bit Registers''

== IO-Register als Parameter und Variablen ==

Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <util/delay.h>

uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)
{
static uint8_t last_state = 0;

if (last_state == (*inputreg & (1<<inputbit)))
return 0; /* keine Änderung */

/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */
_delay_ms(20);

/* Zustand für nächsten Aufruf merken: */
last_state = *inputreg & (1<<inputbit);

/* und den entprellten Tastendruck zurückgeben: */
return *inputreg & (1<<inputbit);
}

/* Beispiel für einen Funktionsaufruf: */

void foo (void)
{
uint8_t i = key_pressed (&PINB, PB1);
}
</syntaxhighlight>

Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.

Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]

= Zugriff auf IO-Ports =

Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen
* bei Ausgängen deren Zustand festzulegen
* bei Eingängen deren Zustand zu erfassen

Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).

Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.

Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.

Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:

{| class="wikitable"
|-
! DDRx
| Datenrichtungsregister für Port'''x'''.
'''x''' entspricht '''A''', '''B''', ''' C''', '''D''' usw. (abhängig von der Anzahl der Ports des verwendeten AVR). Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.
|-
! PINx
| Eingangsadresse für Port'''x'''.
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.
|-
! PORTx
| Datenregister für Port'''x'''.
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).
|}

Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.

== Datenrichtung bestimmen ==

Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.

Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang
verwendet werden, muss das entsprechende Bit gelöscht sein.

Beispiel:
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen

+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

In C liest sich das dann so:

<syntaxhighlight lang="c">
// in io.h wird u.a. DDRB definiert:
#include <avr/io.h>

int main()
{
// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
// direkte Zuweisung - standardkonform */
DDRB = 0x1F; /*

// übersichtliche Alternative - Binärschreibweise, aber kein ISO-C
DDRB = 0b00011111;

// Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
// aber übersichtlicher und selbsterklärend:
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);
</syntaxhighlight>

Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:

<syntaxhighlight lang="c">
// Alle Pins des Ports B als Ausgang definieren:
DDRB = 0xff;
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~(1 << DDB0);
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~((1 << DDB3) | (1 << DDB4));
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
DDRB |= (1 << DDB0) | (1 << DDB3);
// Alle Pins auf Eingang:
DDRB = 0x00;
</syntaxhighlight>

== Vordefinierte Bitnummern für I/O-Register ==

Die Bitnummern (z. B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):

<syntaxhighlight lang="c">
...
/* PORTC */
#define PC7 7
#define PC6 6
#define PC5 5
#define PC4 4
#define PC3 3
#define PC2 2
#define PC1 1
#define PC0 0

/* DDRC */
#define DDC7 7
#define DDC6 6
#define DDC5 5
#define DDC4 4
#define DDC3 3
#define DDC2 2
#define DDC1 1
#define DDC0 0

/* PINC */
#define PINC7 7
#define PINC6 6
#define PINC5 5
#define PINC4 4
#define PINC3 3
#define PINC2 2
#define PINC1 1
#define PINC0 0
</syntaxhighlight>

== Digitale Signale ==

Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.

== Ausgänge ==
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.

Mit dem Befehl
<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = 0x04; /* besser PORTB=(1<<PB2) */

// übersichtliche Alternative - Binärschreibweise
PORTB = 0b00000100; /* direkte Zuweisung - übersichtlich */

</syntaxhighlight>
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).

Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */
/* vereinfacht durch Nutzung des |= Operators : */
PORTB |= (1<<PB2);

/* auch mehrere "gleichzeitig": */
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */
</syntaxhighlight>

"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */
</syntaxhighlight>
Siehe auch [[Bitmanipulation]]

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.

''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''

Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:
* zuerst die Bits im PORTx-Register setzen
* anschließend die Datenrichtung auf Ausgang stellen

Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:
* setze PORTx: interner Pull-Up aktiv
* setze DDRx: Ausgang ("high")

Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.

== Eingänge (Wie kommen Signale in den µC) ==

Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.

=== Signalkopplung ===

Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.

Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z. B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.

Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.

{| class="wikitable" style="text-align:center"
|+ '''Spannungstabelle''' (ca. Grenzwerte)
|
! Low || High
|-
! bei 5 V
| 1 V || 3,5 V
|-
! bei 3,3 V
| 0,66 V || 2,31 V
|-
! bei 1,8 V
| 0,36 V || 1,26 V
|}

Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.

{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}

Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>
...
uint8_t bPortD;
...
bPortD = PIND;
...
</syntaxhighlight>

Mit den C-Bitoperationen kann man den Status der Bits abfragen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */
if ( PINC & (1<<PINC1) ) {
/* Aktion */
}

/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */
if ( !(PINB & (1<<PINB2)) ) {
/* Aktion */
}
...
</syntaxhighlight>
Siehe auch [[Bitmanipulation#Bits_prüfen]]

=== Interne Pull-Up Widerstände ===

Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z. B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.

Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.

Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.

Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRD = 0x00; /* alle Pins von Port D als Eingang */
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */
...
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */
</syntaxhighlight>

=== Taster und Schalter ===

Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.

<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC">
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten.
</gallery>

Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z. B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.

==== Taster entprellen ====

Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]

= Warteschleifen (delay.h) =

Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:

* Warten im Sinn von Zeitvertrödeln
* Warten auf einen bestimmten Zustand an den I/O-Pins
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)
* Warten auf einen bestimmten Zählerstand (siehe Counter)

Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.

Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z. B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z. B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden.

Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.

Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...

Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.

== avr-libc Versionen bis 1.6 ==

Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z. B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */

/*
lange, variable Verzögerungszeit, Einheit in Millisekunden

Die maximale Zeit pro Funktionsaufruf ist begrenzt auf
262.14 ms / F_CPU in MHz (im Beispiel:
262.1 / 3.6864 = max. 71 ms)

Daher wird die kleine Warteschleife mehrfach aufgerufen,
um auf eine längere Wartezeit zu kommen. Die zusätzliche
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig
ungenau werden (macht hier vielleicht 2-3ms aus).
*/

void long_delay(uint16_t ms)
{
for(; ms>0; ms--) _delay_ms(1);
}

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) // Endlosschleife
{
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z. B. angeschlossene LED
long_delay(1000); // Eine Sekunde warten...
}

return 0;
}
</syntaxhighlight>

== avr-libc Versionen ab 1.7 ==

_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.

Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...
// funktioniert nicht mit Bibliotheken vor 1.6

}
return 0;
}
</syntaxhighlight>

Trick zur Übergabe einer Variablen an _delay_ms():
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

void sleep ( uint8_t ms )
{
for(; ms > 0; ms--) _delay_ms(1);
}

int main( void )
{
int x = 0; // Variable als Wartezeit erstellen
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
sleep(x);
x++;
}
return 0;
}
</syntaxhighlight>

Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]

= Programmieren mit Interrupts =

<div style="float:right; margin:2em;">
[[Image:Interrupt Programme.gif]]
</div>
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich
die Programmierung unter Zuhilfenahme der Interrupts des AVR.

Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).

Um Interrupts verarbeiten zu können, ist folgendes zu beachten:

* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).

Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.

Siehe auch

* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]
* Artikel [[Interrupt]]
* Artikel [[Multitasking]]
{{Clear}}

== Anforderungen an Interrupt-Routinen ==

Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:

* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)
* Keine langen Programmschleifen.
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.

Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.

(*)
Hinweis:
Es gibt allerdings die seltene Situation, dass man gerade eingelesene
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!

== Interrupt-Quellen ==

Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.

* Reset
* Externer Interrupt 0
* Externer Interrupt 1
* Timer/Counter 1 Capture Ereignis
* Timer/Counter 1 Compare Match
* Timer/Counter 1 Überlauf
* Timer/Counter 0 Überlauf
* UART Zeichen empfangen
* UART Datenregister leer
* UART Zeichen gesendet
* Analoger Komparator

Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").

== Register ==

Der AT90S2313 verfügt über 2 Register die mit den
Interrupts zusammenhängen.

{| class="wikitable"
|-
| '''GIMSK'''
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INT1''' (External '''Int'''errupt Request '''1''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

'''INT0''' (External '''Int'''errupt Request '''0''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

|-
| '''GIFR'''
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INTF1''' (External '''Int'''errupt Flag '''1''')
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.

'''INTF0''' (External '''Int'''errupt Flag '''0''')
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.
|-
| '''MCUCR'''
| '''MCU''' '''C'''ontrol '''R'''egister.

Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''
|-
! R/W
| R || R || R/W || R/W || R/W || R/W || R/W || R/W
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0

|}

'''SE''' ('''S'''leep '''E'''nable)
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.

'''SM''' ('''S'''leep '''M'''ode)
:Dieses Bit bestimmt über den Schlafmodus.
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")

'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC11 || ISC10 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT1''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.
|}

'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC01 || ISC00 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT0''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.
|}

|}

== Allgemeines über die Interrupt-Abarbeitung ==

Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist.



== Interrupts mit avr-gcc ==



Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').

<syntaxhighlight lang="c">
// fuer sei(), cli() und ISR():
#include <avr/interrupt.h>
</syntaxhighlight>

Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.

<syntaxhighlight lang="c">
sei();
</syntaxhighlight>

Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.

<syntaxhighlight lang="c">
cli();
</syntaxhighlight>

Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>

//...

void NichtUnterbrechenBitte(void)
{
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister

tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern
cli(); // Interrupts global deaktivieren

/* hier "unterbrechnungsfreier" Code */

/* Beispiel Anfang
JTAG-Interface eines ATmega16 per Software deaktivieren
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229):
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */

MCUCSR |= (1<<JTD);
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information

/* Beispiel Ende */

SREG = tmp_sreg; // Status-Register wieder herstellen
// somit auch das I-Flag auf gesicherten Zustand setzen
}

void NichtSoGut(void)
{
cli();

/* hier "unterbrechnungsfreier" Code */

sei();
}

int main(void)
{
//...

cli();
// Interrupts global deaktiviert

NichtUnterbrechenBitte();
// auch nach Aufruf der Funktion deaktiviert

sei();
// Interrupts global aktiviert

NichtUnterbrechenBitte();
// weiterhin aktiviert
//...

/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */
cli();
// Interrupts jetzt global deaktiviert

NichtSoGut();
// nach Aufruf der Funktion sind Interrupts global aktiviert
// dies ist mglw. ungewollt!
//...

}
</syntaxhighlight>


Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.

=== ISR ===

(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
//...
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */
{
/* Interrupt Code */
}
</syntaxhighlight>

Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.

Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.

<syntaxhighlight lang="c">
//...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */

/* avr/iom8.h - definitions for ATmega8 */
//...

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect _VECTOR(1)
#define SIG_INTERRUPT0 _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect _VECTOR(2)
#define SIG_INTERRUPT1 _VECTOR(2)

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)

/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect _VECTOR(4)
#define SIG_OVERFLOW2 _VECTOR(4)

/* Timer/Counter1 Capture Event */
#define TIMER1_CAPT_vect _VECTOR(5)
#define SIG_INPUT_CAPTURE1 _VECTOR(5)

/* Timer/Counter1 Compare Match A */
#define TIMER1_COMPA_vect _VECTOR(6)
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)

/* Timer/Counter1 Compare Match B */
#define TIMER1_COMPB_vect _VECTOR(7)
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)

//...
</syntaxhighlight>


Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
/* veraltet: #include <avr/signal.h> */

ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */
{
/* Interrupt Code */
}

ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
/* Interrupt Code */
}

ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */
{
/* Interrupt Code */
}

// und so weiter und so fort...
</syntaxhighlight>

Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]).

Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.

Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.

Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.

=== Unterbrechbare Interruptroutinen ===

"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */
{
/* Interrupt-Code */
}
</syntaxhighlight>

Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z. B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden – auch XXX-Interrupts.

Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.

Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR (XXX)
{
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen

<<Deaktiviere die XXX-IRQ>>

// Erlaube alle Interrupts (ausser XXX)
sei();

//... Code ...

// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos
// aktivieren zu koennen
cli();

<<Aktiviere die XXX-IRQ>>
}
</syntaxhighlight>
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.

Siehe auch: Hinweise in [[AVR-GCC]]

siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

== Datenaustausch mit Interrupt-Routinen ==

Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.

Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdint.h>
//...

// Schwellwerte
// Entprellung:
#define CNTDEBOUNCE 10
// "lange gedrueckt:"
#define CNTREPEAT 200

// hier z. B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt
#define KEY_PIN PINA
#define KEY_PINNO PA2

// beachte: volatile!
volatile uint8_t gKeyCounter;

// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt
ISR(TIMER1_COMPA_vect)
{
// hier wird gKeyCounter veraendert. Die übrigen
// Programmteile müssen diese Aenderung "sehen":
// volatile -> aktuellen Wert immer in den Speicher schreiben
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
}
else {
gKeyCounter = 0;
}
}

//...

int main(void)
{
//...
/* hier: Initialisierung der Ports und des Timer-Interrupts */
//...
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der
// ISR geschriebene Wert bekannt sein:
// volatile -> aktuellen Wert immer aus dem Speicher lesen
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"
if (gKeyCounter == CNTREPEAT) {
/* hier: Code fuer "Taste lange gedrueckt" */
}
else {
/* hier: Code fuer "Taste kurz gedrueckt" */
}
}
//...
}
</syntaxhighlight>

Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:

<syntaxhighlight lang="c">
//...
ISR(TIMER1_COMPA_vect)
{
uint8_t tmp_kc;

tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (tmp_kc < CNTREPEAT) {
tmp_kc++;
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc; // Zurueckschreiben
}
//...
</syntaxhighlight>

Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
876: ca 99 sbic 0x19, 2 ; 25
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24>
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
87a: 80 91 2a 03 lds r24, 0x032A
87e: 88 3c cpi r24, 0xC8 ; 200
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28>
882: 80 91 2a 03 lds r24, 0x032A
886: 8f 5f subi r24, 0xFF ; 255
888: 80 93 2a 03 sts 0x032A, r24
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28>
}
else {
gKeyCounter = 0;
88e: 10 92 2a 03 sts 0x032A, r1
892: 8f 91 pop r24
894: 0f 90 pop r0
896: 0f be out 0x3f, r0 ; 63
898: 0f 90 pop r0
89a: 1f 90 pop r1
89c: 18 95 reti
</pre>

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
uint8_t tmp_kc;

tmp_kc = gKeyCounter;
876: 80 91 2a 03 lds r24, 0x032A

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
87a: ca 9b sbis 0x19, 2 ; 25
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18>
87e: 80 e0 ldi r24, 0x00 ; 0
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e>
if (tmp_kc < CNTREPEAT) {
882: 88 3c cpi r24, 0xC8 ; 200
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e>
tmp_kc++;
886: 8f 5f subi r24, 0xFF ; 255
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc;
888: 80 93 2a 03 sts 0x032A, r24
88c: 8f 91 pop r24
88e: 0f 90 pop r0
890: 0f be out 0x3f, r0 ; 63
892: 0f 90 pop r0
894: 1f 90 pop r1
896: 18 95 reti
</pre>

=== volatile und Pointer ===

Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.

<syntaxhighlight lang="c">
volatile uint8_t *a; // das Ziel von a ist volatile

uint8_t *volatile a; // a selbst ist volatile
</syntaxhighlight>

Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.

=== Variablen größer 1 Byte ===

Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:

<syntaxhighlight lang="c">
//...
volatile uint16_t gMyCounter16bit;
//...
ISR(...)
{
//...
gMyCounter16Bit++;
//...
}

int main(void)
{
uint16_t tmpCnt;
//...
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.
tmpCnt = gMyCounter16bit;

// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"
// bleiben konsistent
cli(); // Interrupts deaktivieren
tmpCnt = gMyCounter16Bit;
sei(); // wieder aktivieren

// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten
uint8_t sreg_tmp;
sreg_tmp = SREG; /* Sichern */
cli()
tmpCnt = gMyCounter16Bit;
SREG = sreg_tmp; /* Wiederherstellen */

// oder: mehrfach lesen, bis man konsistente Daten hat
uint16_t count1 = gMyCounter16Bit;
uint16_t count2 = gMyCounter16Bit;
while (count1 != count2) {
count1 = count2;
count2 = gMyCounter16Bit;
}
tmpCnt = count1;
//...
}
</syntaxhighlight>

Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.
<syntaxhighlight lang="c">
//...
#include <util/atomic.h>
//...

// analog zu cli, Zugriff, sei:
ATOMIC_BLOCK(ATOMIC_FORCEON) {
tmpCnt = gMyCounter16Bit;
}

// oder:

// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
tmpCnt = gMyCounter16Bit;
}

//...
</syntaxhighlight>

* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]

== Interrupt-Routinen und Registerzugriffe ==

Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können.

Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main(void)
{
//...
PORTA |= (1<<PA0);

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
//...
}
</syntaxhighlight>

Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:

<div class="code"><pre>
...
PORTA |= (1<<PA0);
d2: d8 9a sbi 0x1b, 0 ; 27 (a)

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
d4: 8b b3 in r24, 0x1b ; 27 (b)
d6: 8c 61 ori r24, 0x1C ; 28 (c)
d8: 8b bb out 0x1b, r24 ; 27 (d)
...
</pre></div>

Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z. B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben.

Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt.

Lösungsmöglichkeiten:
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)

== Interruptflags löschen ==

Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben.

Hinweis: 
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten. 
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).

== Was macht das Hauptprogramm? ==

Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den meisten Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.

Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals

= Sleep-Modes =

AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.

;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z. B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).

Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
...

while (1) {
...
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

// Code hier wird erst nach Auftreten eines entsprechenden
// "Aufwach-Interrupts" verarbeitet
...
}
}
</syntaxhighlight>

In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():

<syntaxhighlight lang="c">
#include <avr/io.h>
...
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren
SMCR = (3<<SM0) | (1<<SE);
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h
...
</syntaxhighlight>

== Sleep Modi ==
Zu beachten ist, dass unterschiedliche Prozessoren aus der AVR Familie unterschiedliche Sleep-Modi unterstützen oder nicht unterstützen. Auskunft über die tatsächlichen Gegebenheiten gibt, wie immer, das zum Prozessor gehörende Datenblatt. Die unterschiedlichen Modi unterscheiden sich dadurch, welche Bereiche des Prozessors abgeschaltet werden. Damit korrespondiert unmittelbar welche Möglichkeiten es gibt, den Prozessor aus den jeweiligen Sleep Modus wieder aufzuwecken.

;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.

;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann. Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.

;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator) gestoppt. Geweckt werden kann die CPU durch einen externen Level Interrupt, TWI, Watchdog, Brown-Out-Reset

;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.

;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators (also einer externen Taktquelle). Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus ist eine kürzere Aufwachzeit.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.

= Zeiger =
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.

Siehe auch: [[Zeiger]]

= Speicherzugriffe =

Atmel AVR-Controller verfügen typisch über drei Speicher:

* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.

* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.

* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z. B. Kalibrierungswerte von Sensoren abgelegt.

Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.

Siehe auch:
* [[Binäre Daten zum Programm hinzufügen]]
== RAM ==

Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.

Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.

Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).

malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.

Beispiel zur Verwendung von malloc():
<syntaxhighlight lang="c">
#include <stdlib.h>

void foo(void) {
// neuen speicherbereich anlegen,
// platz für 10 uint16
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));

// darauf zugreifen, als wärs ein gewohnter Buffer
pBuffer[2] = 5;

// Speicher (unbedingt!) wieder freigeben
free(pBuffer);
}
</syntaxhighlight>

Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.

siehe auch:
* http://www.nongnu.org/avr-libc/user-manual/malloc.html

== Flash mit PROGMEM und pgm_read ==

→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]

Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELMP.

Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:
<syntaxhighlight lang="c">
const int value __attribute__((progmem)) = 1;
</syntaxhighlight>

Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus dem RAM gelesen und nicht aus dem Flash!

Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

const int value PROGMEM = 1;
</syntaxhighlight>

<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.

=== Integer und float ===

Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref>

:{| {{Tabelle}}
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus dem Header <tt>avr/pgmspace.h</tt> der avr-libc
|-
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes
|-
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1
|-
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2
|-
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4
|-
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4
|}

Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.

;Beispiele:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Byte */
const uint8_t aByte PROGMEM = 123;

/* int-Array */
const int anArray[] PROGMEM = { 18, 3 ,70 };

void foo (void)
{
/* Zeiger */
static const uint8_t* const aPointer PROGMEM = &aByte;

uint8_t a = pgm_read_byte (&aByte);
int a2 = (int) pgm_read_word (&anArray[2]);
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);
}
</syntaxhighlight>

=== Blöcke ===

In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.

=== Strings ===

Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

size_t my_string_length (const char* addr)
{
size_t length = 0;

while (pgm_read_byte (addr++))
{
len++;
}
return length;
}
</syntaxhighlight>

Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Liefert true zurück, wenn string_im_ram gleich "Hallo Welt" ist. */
int foo (const char* string_im_ram)
{
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));
}
</syntaxhighlight>

Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.

; Array aus Strings:

Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:

# Zuerst die einzelnen Elemente des Arrays und
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.

Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char str1[] PROGMEM = "Hund";
static const char str2[] PROGMEM = "Katze";
static const char str3[] PROGMEM = "Maus";

const char * const array[] PROGMEM =
{
str1, str2, str3
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Lese die Adresse des i-ten Strings aus array[]
const char *parray = (const char*) pgm_read_word (&array[i]);

// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM
strcpy_P (buf, parray);
}
</syntaxhighlight>

Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.

Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref>

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")
const char array[][6] PROGMEM =
{
"Hund", "Katze", "Maus"
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM
strcpy_P (buf, array[i]);
}
</syntaxhighlight>

Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]

=== Warum so kompliziert? ===

Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.

Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.

Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.

Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities

=== Variablenzugriff >64kB ===

Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Um Flashzugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:

* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc, wie im folgenden beschrieben.

Unverständlicherweise gibt es in der AVR-Libc keine Funktion, um 32-Bit Pointer zu erhalten. Hier schafft ein eigenes GNU-C99 Makro Abhilfe:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/pgmspace.h>

//====================================================================
// Macro to access strings defined in PROGMEM above 64kB
//--------------------------------------------------------------------
#define FAR(var) \
({ uint_farptr_t tmp; \
__asm__ ( \
"ldi %A0, lo8(%1)" "\n\t" \
"ldi %B0, hi8(%1)" "\n\t" \
"ldi %C0, hh8(%1)" \
: "=d" (tmp) \
: "i" (&(var))); \
tmp; \
})
//-------------------------------------------------------------------

//===================================================================
// Define a section above 64kiB (FAR_SECTION)
// and add the required linker argument below
// -Wl,--section-start=.far_section=0x10000
//--------------------------------------------------------------------
#define FAR_SECTION __attribute__((__section__(".far_section")))
//--------------------------------------------------------------------

//====================================================================
// Just a Sample
//--------------------------------------------------------------------

const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};

int main(void)
{
char MyChar;
DDRC = 0xFF;
do
{
MyChar = pgm_read_byte_far(FAR(MyBmp64));
PORTC = MyChar;
}
while(MyChar);
}
</syntaxhighlight>

D.h. man muss
* Das Makro <tt>FAR</tt> im Quellcode einfügen
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen
* Die Variablen mit dieser Section kennzeichnen
* Dem Linker mittels Kommandozeilenoption die Startadrese dieser Section mitteilen

Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich.

<syntaxhighlight lang="c">
int n=3;
MyChar = pgm_read_byte_far(FAR(MyBmp64)+n);
</syntaxhighlight>

== Flash mit __flash und Embedded-C ==

Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.

GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.

<syntaxhighlight lang="c">
static const __flash int value = 10;

int get_value (void)
{
return value;
}
</syntaxhighlight>

# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.

Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse

<syntaxhighlight lang="c">
// val ist eine Variable im Flash
const __flash int val = 42;

// pval liegt auch im Flash und enthält die Adresse von val
const __flash int* const __flash pval = &val;

char get_val (void)
{
// liest den Wert von val über die in pval abgelegte Adresse
return *pval;
}
</syntaxhighlight>

=== Blöcke ===

Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// buf wird auf dem Stack angelegt
data_t buf;

// Kopiere Daten vom Flash nach buf ins RAM
memcpy_P (&buf, pdata, sizeof (data_t));

// Sende die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:

<syntaxhighlight lang="c">
#include <stdlib.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt
const data_t buf = *pdata;

// Verwendet die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

=== Strings ===

Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

#define FSTR(X) ((const __flash char[]) { X } )

const __flash char * const __flash array[] =
{
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")
};

size_t get_len (uint8_t tier)
{
return strlen_P (array[tier]);
}
</syntaxhighlight>

Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.

Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:

<syntaxhighlight lang="c">
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"
const __flash char array[][6] =
{
"Hund", "Katze", "Maus"
};
</syntaxhighlight>

Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:

<syntaxhighlight lang="c">
static const __flash char strHund[] = "Hund";
static const __flash char strKatze[] = "Katze";
static const __flash char strMaus[] = "Maus";

const __flash char * const __flash array[] =
{
strHund, strKatze, strMaus
};
</syntaxhighlight>

=== Casts ===

Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>:

<syntaxhighlight lang="c">
#include <stdbool.h>

char read_char (const char *address, bool data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
</syntaxhighlight>

Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.

=== Jenseits von __flash ===

Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:

; <tt>__flash</tt>''N'': Mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist. Dies wird in Binutils noch nicht unterstützt<ref>[http://sourceware.org/PR14406 Binutils PR14406]: Support .progmem<N>.data sections to work with GCC's [http://gcc.gnu.org/PR49868 PR49868].</ref> (Stand Binutils 2.24) Die Unterstützung kann durch ein eigenes Linker-Skript erreicht werden, welches diese Sections wie vom Compiler erwartet lokatiert.
; <tt>__memx</tt>: Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:

:{|
|-
|<syntaxhighlight lang="c">
const __memx int a_flash = 42;
const int a_ram = 100;

static int get_a (const __memx int* pa)
{
return *pa;
}

int main (void)
{
return get_a (&a_flash) + get_a (&a_ram);
}</syntaxhighlight>
|}Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob aus dem RAM oder aus dem Flash gelesen werden soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik.

=== __flash, progmem und Portierbarkeit ===

Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.

Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.

Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.
<syntaxhighlight lang="c">
static const __flash char x[] = { 'A', 'V', 'R' };

char foo (void)
{
return x[2];
}
</syntaxhighlight>
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.

==== progmem → __flash ====

Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.

Eine Portierung wird man in zwei Schritten vornehmen:

;1. Definitionen von Flash-Variablen werden angepasst:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char hund[] PROGMEM = "Hund";
static const char katze[] PROGMEM = "Katze";
static const char maus[] PROGMEM = "Maus";

const char * const tier[] PROGMEM =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
static const __flash char hund[] = "Hund";
static const __flash char katze[] = "Katze";
static const __flash char maus[] = "Maus";

const __flash char * const __flash tier[] =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.

Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt

; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

extern const char *tier[];

char first_letter (uint8_t i)
{
const char* ptier = (const char*) pgm_read_word (&tier[i]);
return (char) pgm_read_byte (&ptier[0]);
}
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
#include <stdint.h>

extern const __flash char * const __flash tier[];

char first_letter (uint8_t i)
{
return tier[i][0];
}
</syntaxhighlight>
|}

== Dateien direkt im Flash einbinden ==

Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.

* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]

Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.

* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden

== Flash in der Anwendung schreiben ==

Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.

Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.

Siehe auch:
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]

== EEPROM ==

Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.

Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.

Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.

Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle.

Bei geschickter Programmierung (z. B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.

Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).

Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl.

=== EEMEM ===
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:

<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/eeprom.h>

/* Byte */
uint8_t eeFooByte EEMEM = 123;

/* Wort */
uint16_t eeFooWord EEMEM = 12345;

/* float */
float eeFooFloat EEMEM;

/* Byte-Array */
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };

/* 16-bit unsigned short feld */
uint16_t eeFooWordArray1[4] EEMEM;
</syntaxhighlight>

Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.

Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.

=== Bytes lesen/schreiben ===

Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:

<syntaxhighlight lang="c">
#define EEPROM_DEF 0xFF

void eeprom_example (void)
{
uint8_t myByte;

// myByte lesen (Wert = 123)
myByte = eeprom_read_byte (&eeFooByte);

// der Wert 99 wird im EEPROM an die Adresse der
// Variablen eeFooByte geschrieben
myByte = 99;
eeprom_write_byte(&eeFooByte, myByte); // schreiben

myByte = eeprom_read_byte (&eeFooByteArray1[1]);
// myByte hat nun den Wert 3

// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-
// zugriff, da die Werte gleich sind.
eeprom_update_byte(&eeFooByte, myByte);

// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE
// deaktiviert ist (unprogrammed/1)
//
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.

uint8_t fooByteDefault = 222;
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)
{
myByte = fooByteDefault;
}
}
</syntaxhighlight>

=== Wort lesen/schreiben ===

Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:

<syntaxhighlight lang="c">
// lesen
uint16_t myWord = eeprom_read_word (&eeFooWord);

// schreiben
eeprom_write_word (&eeFooWord, 2222);
</syntaxhighlight>

=== Block lesen/schreiben ===

Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.
<syntaxhighlight lang="c">
uint8_t myByteBuffer[3];
uint16_t myWordBuffer[4];

void eeprom_block_example (void)
{
/* Datenblock aus EEPROM lesen */

/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse
in das RAM-Array myByteBuffer */
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);

/* dito mit etwas Absicherung betr. der Länge */
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));

/* und nun mit 16-Bit Array */
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));

/* Datenblock in EEPROM schreiben */
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));
}
</syntaxhighlight>

=== Fließkommawerte lesen/schreiben ===

In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

float eeFloat EEMEM = 12.34f;

float void eeprom_float_example(float value)
{
/* float in EEPROM schreiben */
eeprom_write_float(&eeFloat, value);

/* float aus EEPROM lesen */
return eeprom_read_float(&eeFloat);
}</syntaxhighlight>

=== EEPROM-Speicherabbild in .eep-Datei ===

Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden.

Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].

Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.

Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen.

=== Direkter Zugriff auf EEPROM-Adressen ===

Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende Funktionen hilfreich, um sich die Typecasts zu ersparen:

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

// Byte aus dem EEPROM lesen
uint8_t EEPReadByte(uint16_t addr)
{
return eeprom_read_byte((uint8_t *)addr);
}

// Byte in das EEPROM schreiben
void EEPWriteByte(uint16_t addr, uint8_t val)
{
eeprom_write_byte((uint8_t *)addr, val);
}
</syntaxhighlight>

oder als Makro:

<syntaxhighlight lang="c">
#define EEPReadByte(addr) eeprom_read_byte((uint8_t *)addr)
#define EEPWriteByte(addr, val) eeprom_write_byte((uint8_t *)addr, val)
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="c">
EEPWriteByte(0x20, 128); // Byte an die Adresse 0x20 schreiben
...
Val=EEPReadByte(0x20); // EEPROM-Wert von Adresse 0x20 lesen
</syntaxhighlight>

=== Was steckt dahinter? - EEPROM-Register ===
Auch wenn es normalerweise keinen Grund gibt, in C selbst an den Steuerregistern herumzuschrauben - die eeprom Funktionen erledigen das alles zuverlässig - der Vollständigkeit halber der registermässige technische Unterbau.
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.
;EECR: Ist das Kontrollregister für das EEPROM

Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:

:{| class="wikitable" style="text-align:center"
|+ '''Aufbau des EECR-Registers'''
|-
!Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE
|-
! Read/Write
| R || R || R || R || R/W || R/W || R/W || R/W
|-
!Init Value
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''Bedeutung der Bits'''

;Bit 4-7: nicht belegt

;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.

;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.

;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:
:# EEPROM-Bereitschaft abwarten (EEWE=0)
:# Adresse übergeben an EEAR
:# Daten übergeben an EEDR
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist

;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:
:# Bereitschaft zum Lesen prüfen (EEWE=0)
:# Adresse übergeben an EEAR
:# Lesezyklus auslösen mit EERE = 1
:# Warten, bis Lesevorgang abgeschlossen EERE = 0
:# Daten abholen aus EEDR

= Die Nutzung von sprintf und printf =

Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.

Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.

<syntaxhighlight lang="c">
#include <stdio.h>
#include <stdint.h>

// ...
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)
// ...

uint16_t counter;

// Ausgabe eines unsigned Integerwertes
void uart_puti( uint16_t value )
{
uint8_t puffer[20];

sprintf( puffer, "Zählerstand: %u", value );
uart_puts( puffer );
}

int main()
{
counter = 5;

uart_puti( counter );
uart_puti( 42 );
}
</syntaxhighlight>

Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z. B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdio.h>

void uart_init(void);

// a. Deklaration der primitiven Ausgabefunktion
int uart_putchar(char c, FILE *stream);

// b. Umleiten der Standardausgabe stdout (Teil 1)
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );

// c. Definition der Ausgabefunktion
int uart_putchar( char c, FILE *stream )
{
if( c == '\n' )
uart_putchar( '\r', stream );

loop_until_bit_is_set( UCSRA, UDRE );
UDR = c;
return 0;
}

void uart_init(void)
{
/* hier µC spezifischen Code zur Initialisierung */
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */

// Beispiel:
//
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz
// 9600 Baud 8N1

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
}

int main(void)
{
int16_t antwort = 42;
uart_init();

// b. Umleiten der Standardausgabe stdout (Teil 2)
stdout = &mystdout;

// Anwendung
printf( "Die Antwort ist %d.\n", antwort );
return 0;
}

// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74
// + Ergänzungen
</syntaxhighlight>

Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.

= Anmerkungen =
<references/>

= TODO =
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR
* "naked"-Funktionen

[[Kategorie:avr-gcc Tutorial| ]]

AVR-GCC-Tutorial

2015-12-11T14:29:23Z

Kbuchegg: /* EEPROM-Register */

Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.

Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.

= Vorwort =

In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.

Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.

Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.

Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (nicht immer auf aktuellem Stand).

== Weiterführende Kapitel ==

Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].

;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''

;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''

;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''

;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''

;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''

;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''

;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''

;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''

= Benötigte Werkzeuge =

Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:

* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.

Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.

Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:

* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig.

:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].

* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).

* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].

* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].

= Was tun, wenn's nicht klappt? =

* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.

* Die [[AVR Checkliste]] durcharbeiten.

* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.

* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.

* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.

* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.

* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.

* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).

* Google oder yahoo befragen schadet nie.

* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.

* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.

* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.

= Erzeugen von Maschinencode =

Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z. B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z. B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:

* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z. B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z. B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen.

* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses).

* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.

Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.

= Einführungsbeispiel =

Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.

Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden.

Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.

Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.

<syntaxhighlight lang="c">
/* Alle Zeichen zwischen Schrägstrich-Stern
und Stern-Schrägstrich sind Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h> // (1)

int main (void) { // (2)

DDRB = 0xFF; // (3)
PORTB = 0x03; // (4)

while(1) { // (5)
/* "leere" Schleife*/ // (6)
} // (7)

/* wird nie erreicht */
return 0; // (8)
}
</syntaxhighlight>

# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein <code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein <code>\</code>.
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight>
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.

Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].

<pre>
D:\beispiel>dir

Verzeichnis von D:\beispiel

28.11.2006 22:53 <DIR> .
28.11.2006 22:53 <DIR> ..
28.11.2006 20:06 118 main.c
28.11.2006 20:03 16.810 Makefile
2 Datei(en) 16.928 Bytes
</pre>

Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist.
<pre>
D:\beispiel>make all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -
o obj/main.o

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
--output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex
</pre>

Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z. B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z. B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.

Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.

= Ganzzahlige Datentypen (Integer) =

Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.

Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight>

{| {{Tabelle}}
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''  
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenbehaftete int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −27 ⋯ 27−1 || <code>signed char</code>
|-
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −215 ⋯ 215−1 || <code>signed short</code>, <code>signed int</code>
|-
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −231 ⋯ 231−1 || <code>signed long</code>
|-
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −263 ⋯ 263−1 || <code>signed long long</code>
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenlose int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 28−1 || <code>unsigned char</code>
|-
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 216−1 || <code>unsigned short</code>, <code>unsigned int</code>
|-
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 232−1 || <code>unsigned long</code>
|-
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 264−1 || <code>unsigned long long</code>
|}

Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].

= Grundsätzlicher Programmaufbau eines µC-Programms =

Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in
welcher Programmiersprache das Programm geschrieben wird.

== Sequentieller Programmablauf ==

[[Image:Sequentielle Programme.gif|left]]
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".
{{Absatz}}

== Interruptgesteuerter Programmablauf ==

[[Image:Interrupt Programme.gif|left]]
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.
{{Absatz}}

= Zugriff auf Register =

Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die
Inhalte der Register sowohl auslesen als auch beschreiben.

Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.

Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.

Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:

<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Ist im Makefile der MCU-Typ z. B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.


Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z. B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:

<pre>
[...]
# MCU Type ("name") setzen:
MCU = atmega16
[...]

[...]
## Verwendung des Inhalts von MCU (hier atmega16) fuer die
## Compiler- und Assembler-Parameter
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)
[...]

[...]
## Aufruf des Compilers:
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@
[...]
</pre>

Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:

<syntaxhighlight lang="c">
// avr/io.h
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)
[...]
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
// [...]
#elif defined (__AVR_ATmega16__)
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:
# include <avr/iom16.h>
// [...]
#else
# if !defined(__COMPILING_AVR_LIBC__)
# warning "device type not defined"
# endif
#endif
</syntaxhighlight>

Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z. B. die des UART, ADC, SPI) analog.

== Schreiben in Register ==

Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref>

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main()
{
/* Setzt das Richtungsregister des Ports A auf 0xff
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */
DDRA = 0xff;

/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */
PORTA = 0x03;

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

while (1);
}
</syntaxhighlight>

Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].

Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z. B. DDRB = 0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.

== Verändern von Registerinhalten ==

Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen.

<syntaxhighlight lang="c">
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht
</syntaxhighlight>

Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
#define MEINBIT 2
...
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
</syntaxhighlight>

Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */
</syntaxhighlight>

Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen
</syntaxhighlight>

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.

Siehe auch:
* [[Bitmanipulation]]
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers

== Lesen aus Registern ==

Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>

uint8_t foo;

//...

int main(void)
{
/* kopiert den Status der Eingabepins an PortB
in die Variable foo: */
foo = PINB;
//...
}
</syntaxhighlight>

Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:

<syntaxhighlight lang="c">
#define MEINBIT0 0
#define MEINBIT2 2

uint8_t i;

extern test1();

// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist
i = PINA; // Inhalt in Arbeitsvariable
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)
// falls das Bit gesetzt war, hat i den Inhalt 1
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)?
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen
}
// verkürzt:
if ( ( PINA & 0x01 ) != 0 ) {
test1();
}
// nochmals verkürzt:
if ( PINA & 0x01 ) {
test1();
}
// mit definierter Bitnummer:
if ( PINA & ( 1 << MEINBIT0 ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5)
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)
if ( PINA & 0x05 ) {
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt
}
// mit definierten Bitnummern:
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt
test1();
}

// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist
i = PINA; // einlesen in temporäre Variable
i = i & 0x01; // maskieren von Bit 0
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist
test2();
}
// analog mit not-Operator
if ( !i ) {
test2();
}
// nochmals verkürzt:
if ( !( PINA & 0x01 ) ) {
test2();
}
</syntaxhighlight>

== Warten auf einen bestimmten Zustand ==

Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers).

Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */

#define WARTEPIN PINA
#define WARTEBIT PA2

// mit der avr-libc Funktion:
loop_until_bit_is_set(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// _nicht_ ungleich 0 (also 0) ist.
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}
...
</syntaxhighlight>

Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */
#define WARTEPIN PINB
#define WARTEBIT PB4

// avr-libc-Funktion:
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// gesetzt (1) ist
while ( WARTEPIN & (1<<WARTEBIT) ) {}
...
</syntaxhighlight>

Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers
* [[Bitmanipulation]]

== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==

Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.
<syntaxhighlight lang="c">
#include <avr/io.h>
...
uint16_t foo;

/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */
foo = ADC;
</syntaxhighlight>

Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:

<syntaxhighlight lang="c">
#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

...
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;

UBRRH = (uint8_t) (baud >> 8);
UBRRL = (uint8_t) baud;
...
</syntaxhighlight>

Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''.

Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z. B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann.

Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.

Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.

Das bedeutet für die Reihenfolge:
* Lesezugriff: Erst Low-Byte, dann High-Byte
* Schreibzugriff: Erst High-Byte, dann Low-Byte

Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.

Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!

Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!

In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z. B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.

Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.

Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.

ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt.

Im Umgang mit 16-Bit Registern siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8
* Datenblatt Abschnitt ''Accessing 16-bit Registers''

== IO-Register als Parameter und Variablen ==

Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <util/delay.h>

uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)
{
static uint8_t last_state = 0;

if (last_state == (*inputreg & (1<<inputbit)))
return 0; /* keine Änderung */

/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */
_delay_ms(20);

/* Zustand für nächsten Aufruf merken: */
last_state = *inputreg & (1<<inputbit);

/* und den entprellten Tastendruck zurückgeben: */
return *inputreg & (1<<inputbit);
}

/* Beispiel für einen Funktionsaufruf: */

void foo (void)
{
uint8_t i = key_pressed (&PINB, PB1);
}
</syntaxhighlight>

Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.

Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]

= Zugriff auf IO-Ports =

Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen
* bei Ausgängen deren Zustand festzulegen
* bei Eingängen deren Zustand zu erfassen

Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).

Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.

Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.

Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:

{| class="wikitable"
|-
! DDRx
| Datenrichtungsregister für Port'''x'''.
'''x''' entspricht '''A''', '''B''', ''' C''', '''D''' usw. (abhängig von der Anzahl der Ports des verwendeten AVR). Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.
|-
! PINx
| Eingangsadresse für Port'''x'''.
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.
|-
! PORTx
| Datenregister für Port'''x'''.
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).
|}

Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.

== Datenrichtung bestimmen ==

Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.

Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang
verwendet werden, muss das entsprechende Bit gelöscht sein.

Beispiel:
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen

+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

In C liest sich das dann so:

<syntaxhighlight lang="c">
// in io.h wird u.a. DDRB definiert:
#include <avr/io.h>

int main()
{
// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
// direkte Zuweisung - standardkonform */
DDRB = 0x1F; /*

// übersichtliche Alternative - Binärschreibweise, aber kein ISO-C
DDRB = 0b00011111;

// Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
// aber übersichtlicher und selbsterklärend:
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);
</syntaxhighlight>

Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:

<syntaxhighlight lang="c">
// Alle Pins des Ports B als Ausgang definieren:
DDRB = 0xff;
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~(1 << DDB0);
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~((1 << DDB3) | (1 << DDB4));
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
DDRB |= (1 << DDB0) | (1 << DDB3);
// Alle Pins auf Eingang:
DDRB = 0x00;
</syntaxhighlight>

== Vordefinierte Bitnummern für I/O-Register ==

Die Bitnummern (z. B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):

<syntaxhighlight lang="c">
...
/* PORTC */
#define PC7 7
#define PC6 6
#define PC5 5
#define PC4 4
#define PC3 3
#define PC2 2
#define PC1 1
#define PC0 0

/* DDRC */
#define DDC7 7
#define DDC6 6
#define DDC5 5
#define DDC4 4
#define DDC3 3
#define DDC2 2
#define DDC1 1
#define DDC0 0

/* PINC */
#define PINC7 7
#define PINC6 6
#define PINC5 5
#define PINC4 4
#define PINC3 3
#define PINC2 2
#define PINC1 1
#define PINC0 0
</syntaxhighlight>

== Digitale Signale ==

Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.

== Ausgänge ==
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.

Mit dem Befehl
<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = 0x04; /* besser PORTB=(1<<PB2) */

// übersichtliche Alternative - Binärschreibweise
PORTB = 0b00000100; /* direkte Zuweisung - übersichtlich */

</syntaxhighlight>
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).

Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */
/* vereinfacht durch Nutzung des |= Operators : */
PORTB |= (1<<PB2);

/* auch mehrere "gleichzeitig": */
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */
</syntaxhighlight>

"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */
</syntaxhighlight>
Siehe auch [[Bitmanipulation]]

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.

''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''

Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:
* zuerst die Bits im PORTx-Register setzen
* anschließend die Datenrichtung auf Ausgang stellen

Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:
* setze PORTx: interner Pull-Up aktiv
* setze DDRx: Ausgang ("high")

Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.

== Eingänge (Wie kommen Signale in den µC) ==

Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.

=== Signalkopplung ===

Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.

Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z. B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.

Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.

{| class="wikitable" style="text-align:center"
|+ '''Spannungstabelle''' (ca. Grenzwerte)
|
! Low || High
|-
! bei 5 V
| 1 V || 3,5 V
|-
! bei 3,3 V
| 0,66 V || 2,31 V
|-
! bei 1,8 V
| 0,36 V || 1,26 V
|}

Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.

{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}

Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>
...
uint8_t bPortD;
...
bPortD = PIND;
...
</syntaxhighlight>

Mit den C-Bitoperationen kann man den Status der Bits abfragen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */
if ( PINC & (1<<PINC1) ) {
/* Aktion */
}

/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */
if ( !(PINB & (1<<PINB2)) ) {
/* Aktion */
}
...
</syntaxhighlight>
Siehe auch [[Bitmanipulation#Bits_prüfen]]

=== Interne Pull-Up Widerstände ===

Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z. B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.

Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.

Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.

Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRD = 0x00; /* alle Pins von Port D als Eingang */
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */
...
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */
</syntaxhighlight>

=== Taster und Schalter ===

Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.

<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC">
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten.
</gallery>

Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z. B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.

==== Taster entprellen ====

Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]

= Warteschleifen (delay.h) =

Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:

* Warten im Sinn von Zeitvertrödeln
* Warten auf einen bestimmten Zustand an den I/O-Pins
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)
* Warten auf einen bestimmten Zählerstand (siehe Counter)

Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.

Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z. B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z. B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden.

Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.

Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...

Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.

== avr-libc Versionen bis 1.6 ==

Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z. B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */

/*
lange, variable Verzögerungszeit, Einheit in Millisekunden

Die maximale Zeit pro Funktionsaufruf ist begrenzt auf
262.14 ms / F_CPU in MHz (im Beispiel:
262.1 / 3.6864 = max. 71 ms)

Daher wird die kleine Warteschleife mehrfach aufgerufen,
um auf eine längere Wartezeit zu kommen. Die zusätzliche
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig
ungenau werden (macht hier vielleicht 2-3ms aus).
*/

void long_delay(uint16_t ms)
{
for(; ms>0; ms--) _delay_ms(1);
}

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) // Endlosschleife
{
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z. B. angeschlossene LED
long_delay(1000); // Eine Sekunde warten...
}

return 0;
}
</syntaxhighlight>

== avr-libc Versionen ab 1.7 ==

_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.

Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...
// funktioniert nicht mit Bibliotheken vor 1.6

}
return 0;
}
</syntaxhighlight>

Trick zur Übergabe einer Variablen an _delay_ms():
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

void sleep ( uint8_t ms )
{
for(; ms > 0; ms--) _delay_ms(1);
}

int main( void )
{
int x = 0; // Variable als Wartezeit erstellen
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
sleep(x);
x++;
}
return 0;
}
</syntaxhighlight>

Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]

= Programmieren mit Interrupts =

<div style="float:right; margin:2em;">
[[Image:Interrupt Programme.gif]]
</div>
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich
die Programmierung unter Zuhilfenahme der Interrupts des AVR.

Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).

Um Interrupts verarbeiten zu können, ist folgendes zu beachten:

* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).

Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.

Siehe auch

* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]
* Artikel [[Interrupt]]
* Artikel [[Multitasking]]
{{Clear}}

== Anforderungen an Interrupt-Routinen ==

Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:

* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)
* Keine langen Programmschleifen.
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.

Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.

(*)
Hinweis:
Es gibt allerdings die seltene Situation, dass man gerade eingelesene
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!

== Interrupt-Quellen ==

Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.

* Reset
* Externer Interrupt 0
* Externer Interrupt 1
* Timer/Counter 1 Capture Ereignis
* Timer/Counter 1 Compare Match
* Timer/Counter 1 Überlauf
* Timer/Counter 0 Überlauf
* UART Zeichen empfangen
* UART Datenregister leer
* UART Zeichen gesendet
* Analoger Komparator

Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").

== Register ==

Der AT90S2313 verfügt über 2 Register die mit den
Interrupts zusammenhängen.

{| class="wikitable"
|-
| '''GIMSK'''
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INT1''' (External '''Int'''errupt Request '''1''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

'''INT0''' (External '''Int'''errupt Request '''0''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

|-
| '''GIFR'''
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INTF1''' (External '''Int'''errupt Flag '''1''')
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.

'''INTF0''' (External '''Int'''errupt Flag '''0''')
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.
|-
| '''MCUCR'''
| '''MCU''' '''C'''ontrol '''R'''egister.

Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''
|-
! R/W
| R || R || R/W || R/W || R/W || R/W || R/W || R/W
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0

|}

'''SE''' ('''S'''leep '''E'''nable)
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.

'''SM''' ('''S'''leep '''M'''ode)
:Dieses Bit bestimmt über den Schlafmodus.
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")

'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC11 || ISC10 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT1''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.
|}

'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC01 || ISC00 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT0''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.
|}

|}

== Allgemeines über die Interrupt-Abarbeitung ==

Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist.



== Interrupts mit avr-gcc ==



Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').

<syntaxhighlight lang="c">
// fuer sei(), cli() und ISR():
#include <avr/interrupt.h>
</syntaxhighlight>

Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.

<syntaxhighlight lang="c">
sei();
</syntaxhighlight>

Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.

<syntaxhighlight lang="c">
cli();
</syntaxhighlight>

Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>

//...

void NichtUnterbrechenBitte(void)
{
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister

tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern
cli(); // Interrupts global deaktivieren

/* hier "unterbrechnungsfreier" Code */

/* Beispiel Anfang
JTAG-Interface eines ATmega16 per Software deaktivieren
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229):
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */

MCUCSR |= (1<<JTD);
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information

/* Beispiel Ende */

SREG = tmp_sreg; // Status-Register wieder herstellen
// somit auch das I-Flag auf gesicherten Zustand setzen
}

void NichtSoGut(void)
{
cli();

/* hier "unterbrechnungsfreier" Code */

sei();
}

int main(void)
{
//...

cli();
// Interrupts global deaktiviert

NichtUnterbrechenBitte();
// auch nach Aufruf der Funktion deaktiviert

sei();
// Interrupts global aktiviert

NichtUnterbrechenBitte();
// weiterhin aktiviert
//...

/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */
cli();
// Interrupts jetzt global deaktiviert

NichtSoGut();
// nach Aufruf der Funktion sind Interrupts global aktiviert
// dies ist mglw. ungewollt!
//...

}
</syntaxhighlight>


Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.

=== ISR ===

(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
//...
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */
{
/* Interrupt Code */
}
</syntaxhighlight>

Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.

Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.

<syntaxhighlight lang="c">
//...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */

/* avr/iom8.h - definitions for ATmega8 */
//...

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect _VECTOR(1)
#define SIG_INTERRUPT0 _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect _VECTOR(2)
#define SIG_INTERRUPT1 _VECTOR(2)

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)

/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect _VECTOR(4)
#define SIG_OVERFLOW2 _VECTOR(4)

/* Timer/Counter1 Capture Event */
#define TIMER1_CAPT_vect _VECTOR(5)
#define SIG_INPUT_CAPTURE1 _VECTOR(5)

/* Timer/Counter1 Compare Match A */
#define TIMER1_COMPA_vect _VECTOR(6)
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)

/* Timer/Counter1 Compare Match B */
#define TIMER1_COMPB_vect _VECTOR(7)
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)

//...
</syntaxhighlight>


Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
/* veraltet: #include <avr/signal.h> */

ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */
{
/* Interrupt Code */
}

ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
/* Interrupt Code */
}

ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */
{
/* Interrupt Code */
}

// und so weiter und so fort...
</syntaxhighlight>

Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]).

Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.

Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.

Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.

=== Unterbrechbare Interruptroutinen ===

"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */
{
/* Interrupt-Code */
}
</syntaxhighlight>

Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z. B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden – auch XXX-Interrupts.

Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.

Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR (XXX)
{
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen

<<Deaktiviere die XXX-IRQ>>

// Erlaube alle Interrupts (ausser XXX)
sei();

//... Code ...

// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos
// aktivieren zu koennen
cli();

<<Aktiviere die XXX-IRQ>>
}
</syntaxhighlight>
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.

Siehe auch: Hinweise in [[AVR-GCC]]

siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

== Datenaustausch mit Interrupt-Routinen ==

Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.

Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdint.h>
//...

// Schwellwerte
// Entprellung:
#define CNTDEBOUNCE 10
// "lange gedrueckt:"
#define CNTREPEAT 200

// hier z. B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt
#define KEY_PIN PINA
#define KEY_PINNO PA2

// beachte: volatile!
volatile uint8_t gKeyCounter;

// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt
ISR(TIMER1_COMPA_vect)
{
// hier wird gKeyCounter veraendert. Die übrigen
// Programmteile müssen diese Aenderung "sehen":
// volatile -> aktuellen Wert immer in den Speicher schreiben
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
}
else {
gKeyCounter = 0;
}
}

//...

int main(void)
{
//...
/* hier: Initialisierung der Ports und des Timer-Interrupts */
//...
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der
// ISR geschriebene Wert bekannt sein:
// volatile -> aktuellen Wert immer aus dem Speicher lesen
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"
if (gKeyCounter == CNTREPEAT) {
/* hier: Code fuer "Taste lange gedrueckt" */
}
else {
/* hier: Code fuer "Taste kurz gedrueckt" */
}
}
//...
}
</syntaxhighlight>

Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:

<syntaxhighlight lang="c">
//...
ISR(TIMER1_COMPA_vect)
{
uint8_t tmp_kc;

tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (tmp_kc < CNTREPEAT) {
tmp_kc++;
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc; // Zurueckschreiben
}
//...
</syntaxhighlight>

Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
876: ca 99 sbic 0x19, 2 ; 25
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24>
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
87a: 80 91 2a 03 lds r24, 0x032A
87e: 88 3c cpi r24, 0xC8 ; 200
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28>
882: 80 91 2a 03 lds r24, 0x032A
886: 8f 5f subi r24, 0xFF ; 255
888: 80 93 2a 03 sts 0x032A, r24
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28>
}
else {
gKeyCounter = 0;
88e: 10 92 2a 03 sts 0x032A, r1
892: 8f 91 pop r24
894: 0f 90 pop r0
896: 0f be out 0x3f, r0 ; 63
898: 0f 90 pop r0
89a: 1f 90 pop r1
89c: 18 95 reti
</pre>

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
uint8_t tmp_kc;

tmp_kc = gKeyCounter;
876: 80 91 2a 03 lds r24, 0x032A

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
87a: ca 9b sbis 0x19, 2 ; 25
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18>
87e: 80 e0 ldi r24, 0x00 ; 0
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e>
if (tmp_kc < CNTREPEAT) {
882: 88 3c cpi r24, 0xC8 ; 200
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e>
tmp_kc++;
886: 8f 5f subi r24, 0xFF ; 255
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc;
888: 80 93 2a 03 sts 0x032A, r24
88c: 8f 91 pop r24
88e: 0f 90 pop r0
890: 0f be out 0x3f, r0 ; 63
892: 0f 90 pop r0
894: 1f 90 pop r1
896: 18 95 reti
</pre>

=== volatile und Pointer ===

Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.

<syntaxhighlight lang="c">
volatile uint8_t *a; // das Ziel von a ist volatile

uint8_t *volatile a; // a selbst ist volatile
</syntaxhighlight>

Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.

=== Variablen größer 1 Byte ===

Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:

<syntaxhighlight lang="c">
//...
volatile uint16_t gMyCounter16bit;
//...
ISR(...)
{
//...
gMyCounter16Bit++;
//...
}

int main(void)
{
uint16_t tmpCnt;
//...
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.
tmpCnt = gMyCounter16bit;

// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"
// bleiben konsistent
cli(); // Interrupts deaktivieren
tmpCnt = gMyCounter16Bit;
sei(); // wieder aktivieren

// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten
uint8_t sreg_tmp;
sreg_tmp = SREG; /* Sichern */
cli()
tmpCnt = gMyCounter16Bit;
SREG = sreg_tmp; /* Wiederherstellen */

// oder: mehrfach lesen, bis man konsistente Daten hat
uint16_t count1 = gMyCounter16Bit;
uint16_t count2 = gMyCounter16Bit;
while (count1 != count2) {
count1 = count2;
count2 = gMyCounter16Bit;
}
tmpCnt = count1;
//...
}
</syntaxhighlight>

Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.
<syntaxhighlight lang="c">
//...
#include <util/atomic.h>
//...

// analog zu cli, Zugriff, sei:
ATOMIC_BLOCK(ATOMIC_FORCEON) {
tmpCnt = gMyCounter16Bit;
}

// oder:

// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
tmpCnt = gMyCounter16Bit;
}

//...
</syntaxhighlight>

* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]

== Interrupt-Routinen und Registerzugriffe ==

Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können.

Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main(void)
{
//...
PORTA |= (1<<PA0);

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
//...
}
</syntaxhighlight>

Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:

<div class="code"><pre>
...
PORTA |= (1<<PA0);
d2: d8 9a sbi 0x1b, 0 ; 27 (a)

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
d4: 8b b3 in r24, 0x1b ; 27 (b)
d6: 8c 61 ori r24, 0x1C ; 28 (c)
d8: 8b bb out 0x1b, r24 ; 27 (d)
...
</pre></div>

Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z. B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben.

Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt.

Lösungsmöglichkeiten:
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)

== Interruptflags löschen ==

Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben.

Hinweis: 
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten. 
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).

== Was macht das Hauptprogramm? ==

Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den meisten Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.

Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals

= Sleep-Modes =

AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.

;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z. B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).

Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
...

while (1) {
...
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

// Code hier wird erst nach Auftreten eines entsprechenden
// "Aufwach-Interrupts" verarbeitet
...
}
}
</syntaxhighlight>

In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():

<syntaxhighlight lang="c">
#include <avr/io.h>
...
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren
SMCR = (3<<SM0) | (1<<SE);
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h
...
</syntaxhighlight>

== Sleep Modi ==
Zu beachten ist, dass unterschiedliche Prozessoren aus der AVR Familie unterschiedliche Sleep-Modi unterstützen oder nicht unterstützen. Auskunft über die tatsächlichen Gegebenheiten gibt, wie immer, das zum Prozessor gehörende Datenblatt. Die unterschiedlichen Modi unterscheiden sich dadurch, welche Bereiche des Prozessors abgeschaltet werden. Damit korrespondiert unmittelbar welche Möglichkeiten es gibt, den Prozessor aus den jeweiligen Sleep Modus wieder aufzuwecken.

;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.

;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann. Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.

;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator) gestoppt. Geweckt werden kann die CPU durch einen externen Level Interrupt, TWI, Watchdog, Brown-Out-Reset

;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.

;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators (also einer externen Taktquelle). Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus ist eine kürzere Aufwachzeit.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.

= Zeiger =
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.

Siehe auch: [[Zeiger]]

= Speicherzugriffe =

Atmel AVR-Controller verfügen typisch über drei Speicher:

* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.

* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.

* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z. B. Kalibrierungswerte von Sensoren abgelegt.

Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.

Siehe auch:
* [[Binäre Daten zum Programm hinzufügen]]
== RAM ==

Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.

Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.

Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).

malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.

Beispiel zur Verwendung von malloc():
<syntaxhighlight lang="c">
#include <stdlib.h>

void foo(void) {
// neuen speicherbereich anlegen,
// platz für 10 uint16
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));

// darauf zugreifen, als wärs ein gewohnter Buffer
pBuffer[2] = 5;

// Speicher (unbedingt!) wieder freigeben
free(pBuffer);
}
</syntaxhighlight>

Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.

siehe auch:
* http://www.nongnu.org/avr-libc/user-manual/malloc.html

== Flash mit PROGMEM und pgm_read ==

→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]

Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELMP.

Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:
<syntaxhighlight lang="c">
const int value __attribute__((progmem)) = 1;
</syntaxhighlight>

Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus dem RAM gelesen und nicht aus dem Flash!

Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

const int value PROGMEM = 1;
</syntaxhighlight>

<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.

=== Integer und float ===

Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref>

:{| {{Tabelle}}
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus dem Header <tt>avr/pgmspace.h</tt> der avr-libc
|-
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes
|-
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1
|-
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2
|-
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4
|-
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4
|}

Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.

;Beispiele:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Byte */
const uint8_t aByte PROGMEM = 123;

/* int-Array */
const int anArray[] PROGMEM = { 18, 3 ,70 };

void foo (void)
{
/* Zeiger */
static const uint8_t* const aPointer PROGMEM = &aByte;

uint8_t a = pgm_read_byte (&aByte);
int a2 = (int) pgm_read_word (&anArray[2]);
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);
}
</syntaxhighlight>

=== Blöcke ===

In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.

=== Strings ===

Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

size_t my_string_length (const char* addr)
{
size_t length = 0;

while (pgm_read_byte (addr++))
{
len++;
}
return length;
}
</syntaxhighlight>

Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Liefert true zurück, wenn string_im_ram gleich "Hallo Welt" ist. */
int foo (const char* string_im_ram)
{
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));
}
</syntaxhighlight>

Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.

; Array aus Strings:

Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:

# Zuerst die einzelnen Elemente des Arrays und
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.

Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char str1[] PROGMEM = "Hund";
static const char str2[] PROGMEM = "Katze";
static const char str3[] PROGMEM = "Maus";

const char * const array[] PROGMEM =
{
str1, str2, str3
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Lese die Adresse des i-ten Strings aus array[]
const char *parray = (const char*) pgm_read_word (&array[i]);

// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM
strcpy_P (buf, parray);
}
</syntaxhighlight>

Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.

Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref>

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")
const char array[][6] PROGMEM =
{
"Hund", "Katze", "Maus"
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM
strcpy_P (buf, array[i]);
}
</syntaxhighlight>

Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]

=== Warum so kompliziert? ===

Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.

Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.

Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.

Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities

=== Variablenzugriff >64kB ===

Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Um Flashzugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:

* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc, wie im folgenden beschrieben.

Unverständlicherweise gibt es in der AVR-Libc keine Funktion, um 32-Bit Pointer zu erhalten. Hier schafft ein eigenes GNU-C99 Makro Abhilfe:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/pgmspace.h>

//====================================================================
// Macro to access strings defined in PROGMEM above 64kB
//--------------------------------------------------------------------
#define FAR(var) \
({ uint_farptr_t tmp; \
__asm__ ( \
"ldi %A0, lo8(%1)" "\n\t" \
"ldi %B0, hi8(%1)" "\n\t" \
"ldi %C0, hh8(%1)" \
: "=d" (tmp) \
: "i" (&(var))); \
tmp; \
})
//-------------------------------------------------------------------

//===================================================================
// Define a section above 64kiB (FAR_SECTION)
// and add the required linker argument below
// -Wl,--section-start=.far_section=0x10000
//--------------------------------------------------------------------
#define FAR_SECTION __attribute__((__section__(".far_section")))
//--------------------------------------------------------------------

//====================================================================
// Just a Sample
//--------------------------------------------------------------------

const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};

int main(void)
{
char MyChar;
DDRC = 0xFF;
do
{
MyChar = pgm_read_byte_far(FAR(MyBmp64));
PORTC = MyChar;
}
while(MyChar);
}
</syntaxhighlight>

D.h. man muss
* Das Makro <tt>FAR</tt> im Quellcode einfügen
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen
* Die Variablen mit dieser Section kennzeichnen
* Dem Linker mittels Kommandozeilenoption die Startadrese dieser Section mitteilen

Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich.

<syntaxhighlight lang="c">
int n=3;
MyChar = pgm_read_byte_far(FAR(MyBmp64)+n);
</syntaxhighlight>

== Flash mit __flash und Embedded-C ==

Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.

GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.

<syntaxhighlight lang="c">
static const __flash int value = 10;

int get_value (void)
{
return value;
}
</syntaxhighlight>

# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.

Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse

<syntaxhighlight lang="c">
// val ist eine Variable im Flash
const __flash int val = 42;

// pval liegt auch im Flash und enthält die Adresse von val
const __flash int* const __flash pval = &val;

char get_val (void)
{
// liest den Wert von val über die in pval abgelegte Adresse
return *pval;
}
</syntaxhighlight>

=== Blöcke ===

Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// buf wird auf dem Stack angelegt
data_t buf;

// Kopiere Daten vom Flash nach buf ins RAM
memcpy_P (&buf, pdata, sizeof (data_t));

// Sende die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:

<syntaxhighlight lang="c">
#include <stdlib.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt
const data_t buf = *pdata;

// Verwendet die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

=== Strings ===

Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

#define FSTR(X) ((const __flash char[]) { X } )

const __flash char * const __flash array[] =
{
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")
};

size_t get_len (uint8_t tier)
{
return strlen_P (array[tier]);
}
</syntaxhighlight>

Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.

Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:

<syntaxhighlight lang="c">
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"
const __flash char array[][6] =
{
"Hund", "Katze", "Maus"
};
</syntaxhighlight>

Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:

<syntaxhighlight lang="c">
static const __flash char strHund[] = "Hund";
static const __flash char strKatze[] = "Katze";
static const __flash char strMaus[] = "Maus";

const __flash char * const __flash array[] =
{
strHund, strKatze, strMaus
};
</syntaxhighlight>

=== Casts ===

Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>:

<syntaxhighlight lang="c">
#include <stdbool.h>

char read_char (const char *address, bool data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
</syntaxhighlight>

Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.

=== Jenseits von __flash ===

Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:

; <tt>__flash</tt>''N'': Mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist. Dies wird in Binutils noch nicht unterstützt<ref>[http://sourceware.org/PR14406 Binutils PR14406]: Support .progmem<N>.data sections to work with GCC's [http://gcc.gnu.org/PR49868 PR49868].</ref> (Stand Binutils 2.24) Die Unterstützung kann durch ein eigenes Linker-Skript erreicht werden, welches diese Sections wie vom Compiler erwartet lokatiert.
; <tt>__memx</tt>: Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:

:{|
|-
|<syntaxhighlight lang="c">
const __memx int a_flash = 42;
const int a_ram = 100;

static int get_a (const __memx int* pa)
{
return *pa;
}

int main (void)
{
return get_a (&a_flash) + get_a (&a_ram);
}</syntaxhighlight>
|}Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob aus dem RAM oder aus dem Flash gelesen werden soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik.

=== __flash, progmem und Portierbarkeit ===

Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.

Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.

Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.
<syntaxhighlight lang="c">
static const __flash char x[] = { 'A', 'V', 'R' };

char foo (void)
{
return x[2];
}
</syntaxhighlight>
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.

==== progmem → __flash ====

Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.

Eine Portierung wird man in zwei Schritten vornehmen:

;1. Definitionen von Flash-Variablen werden angepasst:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char hund[] PROGMEM = "Hund";
static const char katze[] PROGMEM = "Katze";
static const char maus[] PROGMEM = "Maus";

const char * const tier[] PROGMEM =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
static const __flash char hund[] = "Hund";
static const __flash char katze[] = "Katze";
static const __flash char maus[] = "Maus";

const __flash char * const __flash tier[] =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.

Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt

; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

extern const char *tier[];

char first_letter (uint8_t i)
{
const char* ptier = (const char*) pgm_read_word (&tier[i]);
return (char) pgm_read_byte (&ptier[0]);
}
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
#include <stdint.h>

extern const __flash char * const __flash tier[];

char first_letter (uint8_t i)
{
return tier[i][0];
}
</syntaxhighlight>
|}

== Dateien direkt im Flash einbinden ==

Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.

* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]

Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.

* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden

== Flash in der Anwendung schreiben ==

Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.

Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.

Siehe auch:
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]

== EEPROM ==

Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.

Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.

Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.

Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle.

Bei geschickter Programmierung (z. B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.

Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).

Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl.

=== EEMEM ===
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:

<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/eeprom.h>

/* Byte */
uint8_t eeFooByte EEMEM = 123;

/* Wort */
uint16_t eeFooWord EEMEM = 12345;

/* float */
float eeFooFloat EEMEM;

/* Byte-Array */
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };

/* 16-bit unsigned short feld */
uint16_t eeFooWordArray1[4] EEMEM;
</syntaxhighlight>

Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.

Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.

=== Bytes lesen/schreiben ===

Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:

<syntaxhighlight lang="c">
#define EEPROM_DEF 0xFF

void eeprom_example (void)
{
uint8_t myByte;

// myByte lesen (Wert = 123)
myByte = eeprom_read_byte (&eeFooByte);

// der Wert 99 wird im EEPROM an die Adresse der
// Variablen eeFooByte geschrieben
myByte = 99;
eeprom_write_byte(&eeFooByte, myByte); // schreiben

myByte = eeprom_read_byte (&eeFooByteArray1[1]);
// myByte hat nun den Wert 3

// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-
// zugriff, da die Werte gleich sind.
eeprom_update_byte(&eeFooByte, myByte);

// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE
// deaktiviert ist (unprogrammed/1)
//
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.

uint8_t fooByteDefault = 222;
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)
{
myByte = fooByteDefault;
}
}
</syntaxhighlight>

=== Wort lesen/schreiben ===

Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:

<syntaxhighlight lang="c">
// lesen
uint16_t myWord = eeprom_read_word (&eeFooWord);

// schreiben
eeprom_write_word (&eeFooWord, 2222);
</syntaxhighlight>

=== Block lesen/schreiben ===

Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.
<syntaxhighlight lang="c">
uint8_t myByteBuffer[3];
uint16_t myWordBuffer[4];

void eeprom_block_example (void)
{
/* Datenblock aus EEPROM lesen */

/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse
in das RAM-Array myByteBuffer */
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);

/* dito mit etwas Absicherung betr. der Länge */
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));

/* und nun mit 16-Bit Array */
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));

/* Datenblock in EEPROM schreiben */
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));
}
</syntaxhighlight>

=== Fließkommawerte lesen/schreiben ===

In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

float eeFloat EEMEM = 12.34f;

float void eeprom_float_example(float value)
{
/* float in EEPROM schreiben */
eeprom_write_float(&eeFloat, value);

/* float aus EEPROM lesen */
return eeprom_read_float(&eeFloat);
}</syntaxhighlight>

=== EEPROM-Speicherabbild in .eep-Datei ===

Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden.

Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].

Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.

Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen.

=== Direkter Zugriff auf EEPROM-Adressen ===

Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende Funktionen hilfreich, um sich die Typecasts zu ersparen:

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

// Byte aus dem EEPROM lesen
uint8_t EEPReadByte(uint16_t addr)
{
return eeprom_read_byte((uint8_t *)addr);
}

// Byte in das EEPROM schreiben
void EEPWriteByte(uint16_t addr, uint8_t val)
{
eeprom_write_byte((uint8_t *)addr, val);
}
</syntaxhighlight>

oder als Makro:

<syntaxhighlight lang="c">
#define EEPReadByte(addr) eeprom_read_byte((uint8_t *)addr)
#define EEPWriteByte(addr, val) eeprom_write_byte((uint8_t *)addr, val)
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="c">
EEPWriteByte(0x20, 128); // Byte an die Adresse 0x20 schreiben
...
Val=EEPReadByte(0x20); // EEPROM-Wert von Adresse 0x20 lesen
</syntaxhighlight>

=== Was steckt dahinter? - EEPROM-Register ===
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.
;EECR: Ist das Kontrollregister für das EEPROM

Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:

:{| class="wikitable" style="text-align:center"
|+ '''Aufbau des EECR-Registers'''
|-
!Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE
|-
! Read/Write
| R || R || R || R || R/W || R/W || R/W || R/W
|-
!Init Value
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''Bedeutung der Bits'''

;Bit 4-7: nicht belegt

;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.

;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.

;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:
:# EEPROM-Bereitschaft abwarten (EEWE=0)
:# Adresse übergeben an EEAR
:# Daten übergeben an EEDR
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist

;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:
:# Bereitschaft zum Lesen prüfen (EEWE=0)
:# Adresse übergeben an EEAR
:# Lesezyklus auslösen mit EERE = 1
:# Warten, bis Lesevorgang abgeschlossen EERE = 0
:# Daten abholen aus EEDR

= Die Nutzung von sprintf und printf =

Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.

Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.

<syntaxhighlight lang="c">
#include <stdio.h>
#include <stdint.h>

// ...
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)
// ...

uint16_t counter;

// Ausgabe eines unsigned Integerwertes
void uart_puti( uint16_t value )
{
uint8_t puffer[20];

sprintf( puffer, "Zählerstand: %u", value );
uart_puts( puffer );
}

int main()
{
counter = 5;

uart_puti( counter );
uart_puti( 42 );
}
</syntaxhighlight>

Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z. B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdio.h>

void uart_init(void);

// a. Deklaration der primitiven Ausgabefunktion
int uart_putchar(char c, FILE *stream);

// b. Umleiten der Standardausgabe stdout (Teil 1)
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );

// c. Definition der Ausgabefunktion
int uart_putchar( char c, FILE *stream )
{
if( c == '\n' )
uart_putchar( '\r', stream );

loop_until_bit_is_set( UCSRA, UDRE );
UDR = c;
return 0;
}

void uart_init(void)
{
/* hier µC spezifischen Code zur Initialisierung */
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */

// Beispiel:
//
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz
// 9600 Baud 8N1

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
}

int main(void)
{
int16_t antwort = 42;
uart_init();

// b. Umleiten der Standardausgabe stdout (Teil 2)
stdout = &mystdout;

// Anwendung
printf( "Die Antwort ist %d.\n", antwort );
return 0;
}

// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74
// + Ergänzungen
</syntaxhighlight>

Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.

= Anmerkungen =
<references/>

= TODO =
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR
* "naked"-Funktionen

[[Kategorie:avr-gcc Tutorial| ]]

AVR-GCC-Tutorial

2015-12-11T14:25:17Z

Kbuchegg: /* EEPROM */

Dieses Tutorial soll den Einstieg in die Programmierung von Atmel [[AVR]]-Mikrocontrollern in der Programmiersprache [[C]] mit dem freien C-Compiler [[avr-gcc]] aus der [http://gcc.gnu.org/ GNU Compiler Collection] (GCC) erleichtern.

Vorausgesetzt werden Grundkenntnisse der Programmiersprache C. Diese Kenntnisse kann man sich online erarbeiten, z. B. mit dem [http://www.schellong.de/c.htm C Tutorial von Helmut Schellong] ([[C|Liste von C-Tutorials]]). Nicht erforderlich sind Vorkenntnisse in der Programmierung von Mikrocontrollern.

= Vorwort =

In diesem Text wird häufig auf die Standardbibliothek avr-libc verwiesen, für die es eine [http://www.nongnu.org/avr-libc/user-manual/index.html Online-Dokumentation] gibt, in der sich auch viele nützliche Informationen zum Compiler und zur Programmierung von AVR-Controllern finden. Beim Paket [[WinAVR]] gehört die avr-libc Dokumentation zum Lieferumfang und wird mitinstalliert.

Der Compiler und die Standardbibliothek avr-libc werden ständig weiterentwickelt. Einige Unterschiede, die sich im Verlauf der Entwicklung ergeben haben, werden hier und im Artikel [[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen]] zwar angesprochen, Anfängern und Umsteigern sei jedoch empfohlen, eine aktuelle Versionen zu nutzen.

Das ursprüngliche Tutorial stammt von Christian Schifferle, viele neue Abschnitte und aktuelle Anpassungen von Martin Thomas.

Dieses Tutorial ist in [[Media:AVR-GCC-Tutorial.pdf|PDF-Form]] erhältlich (nicht immer auf aktuellem Stand).

== Weiterführende Kapitel ==

Um dieses riesige Tutorial etwas überschaubarer zu gestalten, wurden einige Kapitel ausgelagert, die nicht unmittelbar mit den Grundlagen von avr-gcc in Verbindung stehen. All diese Seiten gehören zur [[:Kategorie:avr-gcc Tutorial]].

;UART: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der UART|Der UART]]''

;ADC: → Hauptartikel: ''[[AVR-GCC-Tutorial/Analoge Ein- und Ausgabe|Analoge Ein- und Ausgabe (ADC)]]''

;Timer: → Hauptartikel: ''[[AVR-GCC-Tutorial/Die Timer und Zähler des AVR|Die Timer und Zähler des AVR]]''

;LCD: → Hauptartikel: ''[[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Ansteuerung]]''

;Watchdog: → Hauptartikel: ''[[AVR-GCC-Tutorial/Der Watchdog|Der Watchdog]]''

;Assembler: → Hauptartikel: ''[[AVR-GCC-Tutorial/Assembler und Inline-Assembler|Assembler und Inline-Assembler]]''

;alte Quellen anpassen: → Hauptartikel: ''[[AVR-GCC-Tutorial/Alte Quellen|Alte Quellen anpassen]]''

;Makefiles: → Hauptartikel: ''[[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]]'' sowie als Alternative für sehr kleine Projekte → Hauptartikel: ''[[C ohne Makefile]]''

= Benötigte Werkzeuge =

Um eigene Programme für AVRs mittels einer AVR-Toolchain zu erstellen wird folgende Hard- und Software benötigt:

* Eine AVR-Toolchain bestehend aus avr-gcc, den avr-Binutils (Assembler, Linker, etc) und einer Standard-C Bibliothek. Üblich ist die AVR-LibC, die auch quasi in allen avr-gcc Distributionen enthalten ist.

Hardware wird keine benötigt – bis auf einen PC natürlich, auf dem der Compiler ablaufen kann. Selbst ohne AVR-Hardware kann man also bereits C-Programme für AVRs schreiben, compiliern und sich das Look-and-Feel von avr-gcc sowie von IDEs wie [[Atmel Studio]], Eclipse oder leichtgewichtigeren Entwicklungsumbgebungen anschauen. Selbst das Debuggen und Simulieren ist mithilfe entsprechender Tools wie Debugger und Simulator in gewissen Grenzen möglich.

Um Programme für AVRs mittels einer AVR-Toolchain zu testen, wird folgende Hard- und Software benötigt:

* Platine oder Versuchsaufbau für die Aufnahme eines AVR-Controllers, der vom avr-gcc Compiler unterstützt wird.<ref>Für eine Liste der unterstützten COntroller siehe die Dokumentation des Compilers oder [http://www.nongnu.org/avr-libc/user-manual/index.html#supported_devices AVR-Libc: Supported Devices].</ref> Dieses Testboard kann durchaus auch selbst gelötet oder auf einem Steckbrett aufgebaut werden. Einige Registerbeschreibungen dieses Tutorials beziehen sich auf den inzwischen veralteten AT90S2313. Der weitaus größte Teil des Textes ist aber für alle Controller der AVR-Familie gültig.

:Brauchbare Testplattformen sind auch das [[STK500]] und der [[AVR Butterfly]] von Atmel. Weitere Infos findet man in den Artikeln [[AVR#Starterkits|AVR Starterkits]] und [[AVR-Tutorial: Equipment]].

* Programmiersoftware und -[[AVR In System Programmer |hardware]] z. B. PonyProg (siehe auch: [[Pony-Prog Tutorial]]) oder [[AVRDUDE]] mit [[STK200]]-Dongle oder die von Atmel verfügbare Hard- und Software ([[STK500]], Atmel AVRISP, [[AVR-Studio]]).

* Nicht unbedingt erforderlich, aber zur Simulation und zum Debuggen unter MS-Windows recht nützlich: [[AVR-Studio]].

* Wer unter Windows und Linux gleichermassen entwickeln will, der sollte sich die [http://www.eclipse.org/ IDE Eclipse for C/C++ Developers] und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] ansehen. Beide sind unter Windows und Linux einfach zu installieren, siehe auch [[AVR Eclipse]]. Ebenfalls unter Linux und Windows verfügbar ist die Entwicklungsumgebung [http://www.codeblocks.org/ Code::Blocks]<ref>Aktuelle, stabile Versionen sind als Nightly Builds regelmäßig im [http://forums.codeblocks.org/ Forum] verfügbar.</ref>. Innerhalb dieser Entwicklungsumgebung können ohne die Installation zusätzlicher Plugins "AVR-Projekte" angelegt werden. Für Linux gibt es auch noch das [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=25220 KontrollerLab].

= Was tun, wenn's nicht klappt? =

* Herausfinden, ob es tatsächlich ein avr(-gcc) spezifisches Problem ist oder nur die eigenen C-Kenntnisse einer Auffrischung bedürfen. Allgemeine C-Fragen kann man eventuell "beim freundlichen Programmierer zwei Büro-, Zimmer- oder Haustüren weiter" loswerden. Ansonsten: [[C]]-Buch (gibt's auch "gratis" online) lesen.

* Die [[AVR Checkliste]] durcharbeiten.

* Die '''[http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc]''' lesen, vor allem (aber nicht nur) den Abschnitt Related Pages/'''Frequently Asked Questions''' = Oft gestellte Fragen (und Antworten dazu). Z.Zt leider nur in englischer Sprache verfügbar.

* Den Artikel [[AVR-GCC]] in diesem Wiki lesen.

* Das [http://www.mikrocontroller.net/forum/gcc GCC-Forum auf www.mikrocontroller.net] nach vergleichbaren Problemen absuchen.

* Das avr-gcc-Forum bei [http://www.avrfreaks.net AVRfreaks] nach vergleichbaren Problemen absuchen.

* Das [http://lists.gnu.org/archive/html/avr-gcc-list/ Archiv der avr-gcc Mailing-Liste] nach vergleichbaren Problemen absuchen.

* Nach Beispielcode suchen. Vor allem im ''Projects''-Bereich von [http://www.avrfreaks.net AVRfreaks] (anmelden).

* Google oder yahoo befragen schadet nie.

* Bei Problemen mit der Ansteuerung interner AVR-Funktionen mit C-Code: das Datenblatt des Controllers lesen (ganz und am Besten zweimal). Datenblätter sind auf den [http://www.atmel.com Atmel Webseiten] als pdf-Dateien verfügbar. Das komplette Datenblatt (complete) und nicht die Kurzfassung (summary) verwenden.

* Die Beispielprogramme im [[AVR-Tutorial]] sind zwar in AVR-Assembler verfasst, Erläuterungen und Vorgehensweisen sind aber auch auf C-Programme übertragbar.

* Einen Beitrag in eines der Foren oder eine Mail an die Mailing-Liste schreiben. Dabei möglichst viel Information geben: Controller, Compilerversion, genutzte Bibliotheken, Ausschnitte aus dem Quellcode oder besser ein [http://www.mikrocontroller.net/topic/72767#598986 Testprojekt] mit allen notwendigen Dateien, um das Problem nachzuvollziehen, sowie genaue Fehlermeldungen bzw. Beschreibung des Fehlverhaltens. Bei Ansteuerung externer Geräte die Beschaltung beschreiben oder skizzieren (z. B. mit [http://www.tech-chat.de/ Andys ASCII Circuit]). Siehe dazu auch: '''[http://www.tty1.net/smart-questions_de.html "Wie man Fragen richtig stellt"]'''.

= Erzeugen von Maschinencode =

Aus dem C-Quellcode erzeugt der avr-gcc Compiler (zusammen mit Hilfsprogrammen wie z. B. Präprozessor, Assembler und Linker) Maschinencode für den AVR-Controller. Üblicherweise liegt dieser Code dann im Intel Hex-Format vor ("Hex-Datei"). Die Programmiersoftware (z. B. [[AVRDUDE]], PonyProg oder AVRStudio/STK500-plugin) liest diese Datei ein und überträgt die enthaltene Information (den Maschinencode) in den Speicher des Controllers. Im Prinzip sind also "nur" der avr-gcc-Compiler (und wenige Hilfsprogramme) mit den "richtigen" Optionen aufzurufen, um aus C-Code eine "Hex-Datei" zu erzeugen. Grundsätzlich stehen dazu drei verschiedene Ansätze zur Verfügung:

* Die Verwendung einer integrierten Entwicklungsumgebung (IDE = '''I'''ntegrated '''D'''evelopment '''E'''nvironment), bei der alle Einstellungen z. B. in Dialogboxen durchgeführt werden können. Unter Anderem kann AVRStudio ab Version 4.12 (kostenlos auf [http://www.atmel.com/ atmel.com]) zusammen mit WinAVR als integrierte Entwicklungsumgebung für den Compiler avr-gcc genutzt werden (dazu müssen AVRStudio und WinAVR auf dem Rechner installiert sein). Weitere IDEs (ohne Anspruch auf Vollständigkeit): [http://www.eclipse.org/ Eclipse for C/C++ Developers] (d.h. inkl. CDT) und das [http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin AVR-Eclipse Plugin] (für diverse Plattformen, u.a. Linux und MS Windows, IDE und Plugin kostenlos), [http://sourceforge.net/projects/kontrollerlab KontrollerLab] (Linux/KDE, kostenlos). [http://www.atmanecl.com/EnglishSite/SoftwareEnglish.htm AtmanAvr] (MS Windows, relativ günstig), KamAVR (MS-Windows, kostenlos, wird augenscheinlich nicht mehr weiterentwickelt), [http://www.amctools.com/vmlab.htm VMLab] (MS Windows, ab Version 3.12 ebenfalls kostenlos). Integrierte Entwicklungsumgebungen unterscheiden sich stark in Ihrer Bedienung und stehen auch nicht für alle Plattformen zur Verfügung, auf denen der Compiler ausführbar ist (z. B. AVRStudio nur für MS-Windows). Zur Anwendung des avr-gcc Compilers mit IDEs sei hier auf deren Dokumentation verwiesen.

* Die Nutzung des Programms make mit passenden Makefiles. In den folgenden Abschnitten wird die Generierung von Maschinencode für einen AVR ("hex-Datei") aus C-Quellcode ("c-Dateien") anhand von "make" und den "Makefiles" näher erläutert. Viele der darin beschriebenen Optionen findet man auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio (AVRStudio generiert ein makefile in einem Unterverzeichnis des Projektverzeichnisses).

* Das Generieren des Programms ohne IDE und ohne Makefile. In diesem Fall muss die Quellcodedatei durch eine vorgefertigte Kommandofolge an den Compiler übergeben werden. Der Artikel [[C ohne Makefile]] zeigt, wie das funktioniert. Diese Vorgehensweise empfiehlt sich jedoch nur für kleine Programme, die nicht auf verschiedene Quellcodedateien verteilt sind.

Beim Wechsel vom makefile-Ansatz nach WinAVR-Vorlage zu AVRStudio ist darauf zu achten, dass AVRStudio (Stand: AVRStudio Version 4.13) bei einem neuen Projekt die Optimierungsoption (vgl. Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|AVR-GCC-Tutorial/Exkurs: Makefiles]], typisch: -Os) nicht einstellt und die mathematische Bibliothek der avr-libc (libm.a, Linker-Option -lm) nicht einbindet. (Hinweis: Bei Version 4.16 wird beides bereits gesetzt). Beides ist Standard bei Verwendung von makefiles nach WinAVR-Vorlage und sollte daher auch im Konfigurationsdialog des avr-gcc-Plugins von AVRStudio "manuell" eingestellt werden, um auch mit AVRStudio kompakten Code zu erzeugen.

= Einführungsbeispiel =

Zum Einstieg ein kleines Beispiel, an dem die Nutzung des Compilers und der Hilfsprogramme (der sogenannten ''Toolchain'') demonstriert wird. Detaillierte Erläuterungen folgen in den weiteren Abschnitten dieses Tutorials.

Das Programm soll auf einem AVR Mikrocontroller einige Ausgänge ein- und andere ausschalten. Das Beispiel ist für einen ATmega16 programmiert ([http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Datenblatt]), kann aber sinngemäß für andere Controller der AVR-Familie modifiziert werden.

Ein kurzes Wort zur Hardware: Bei diesem Programm werden alle Pins von PORTB auf Ausgang gesetzt, und einige davon werden auf HIGH andere auf LOW gesetzt. Das kann je nach angeschlossener Hardware an diesen Pins kritisch sein. Am ungefährlichsten ist es, wenn nichts an den Pins angeschlossen ist und man die Funktion des Programmes durch eine Spannungsmessung mit einem Multimeter kontrolliert. Die Spannung wird dabei zwischen GND-Pin und den einzelnen Pins von PORTB gemessen.

Zunächst der Quellcode der Anwendung, der in einer Text-Datei mit dem Namen ''main.c'' abgespeichert wird.

<syntaxhighlight lang="c">
/* Alle Zeichen zwischen Schrägstrich-Stern
und Stern-Schrägstrich sind Kommentare */

// Zeilenkommentare sind ebenfalls möglich
// alle auf die beiden Schrägstriche folgenden
// Zeichen einer Zeile sind Kommentar

#include <avr/io.h> // (1)

int main (void) { // (2)

DDRB = 0xFF; // (3)
PORTB = 0x03; // (4)

while(1) { // (5)
/* "leere" Schleife*/ // (6)
} // (7)

/* wird nie erreicht */
return 0; // (8)
}
</syntaxhighlight>

# In dieser Zeile wird eine sogenannte Header-Datei eingebunden. In <code>avr/io.h</code> sind die Registernamen definiert, die im späteren Verlauf genutzt werden. Auch unter Windows wird ein <code>/</code> zur Kennzeichnung von Unterverzeichnissen in Include-Dateinamen verwendet und kein <code>\</code>.
# Hier beginnt das eigentliche Programm. Jedes C-Programm beginnt mit den Anweisungen in der Funktion <code>main</code>.
# Die Anschlüsse eines AVR (Pins) werden zu Blöcken zusammengefasst, einen solchen Block bezeichnet man als Port. Beim ATmega16 hat jeder Port 8 Anschlüsse, bei kleineren AVRs können einem Port auch weniger als 8 Anschlüsse zugeordnet sein. Da per Definition (Datenblatt) alle gesetzten Bits in einem Datenrichtungsregister den entsprechenden Anschluss auf Ausgang schalten, werden mit DDRB=0xff alle Anschlüsse des Ports B als Ausgänge eingestellt.
# Die den ersten beiden Bits des Ports zugeordneten Anschlüsse (PB0 und PB1) werden 1, alle anderen Anschlüsse des Ports B (PB2-PB7) zu 0. Aktivierte Ausgänge (logisch 1 oder "high") liegen auf Betriebsspannung (VCC, meist 5 Volt), nicht aktivierte Ausgänge führen 0 Volt (GND, Bezugspotential). Es ist sinnvoll, sich möglichst frühzeitig eine alternative Schreibweise beizubringen, die wegen der leichteren Überprüfbarkeit und Portierbarkeit oft im weiteren Tutorial und in Forenbeiträgen benutzt wird. Die Zuordnung sieht in diesem Fall so aus, Näheres dazu im Artikel [[Bitmanipulation]]:<syntaxhighlight lang="c">PORTB = (1<<PB1) | (1<<PB0);</syntaxhighlight>
# ist der Beginn der sogenannte ''Hauptschleife'' (main-loop). Dies ist eine Endlosschleife, welche kontinuierlich wiederkehrende Befehle enthält.
# In diesem Beispiel ist die Hauptschleife leer. Der Controller durchläuft die Schleife immer wieder, ohne dass etwas passiert. Eine solche Schleife ist notwendig, da es auf dem Controller kein Betriebssystem gibt, das nach Beendigung des Programmes die Kontrolle übernehmen könnte. Ohne diese Schleife kehrt das Programm aus <code>main</code> zurück, alle Interrupts werden deaktiviert und eine Endlosschleife betreten.
# Ende der Hauptschleife und Sprung zur passenden, öffnenden Klammer, also zu 5.
# ist das Programmende. Die Zeile ist nur aus Gründen der C-Kompatibilität enthalten: <syntaxhighlight lang="c">int main(void)</syntaxhighlight> besagt, dass die Funktion einen int-Wert zurückgibt. Die Anweisung wird aber nicht erreicht, da das Programm die Hauptschleife nie verlässt.

Um diesen Quellcode in ein lauffähiges Programm zu übersetzen, wird hier ein Makefile genutzt. Das verwendete Makefile findet sich auf der Seite [[Beispiel Makefile]] und basiert auf der Vorlage, die in WinAVR mitgeliefert wird und wurde bereits angepasst (Controllertyp ATmega16). Man kann das Makefile bearbeiten und an andere Controller anpassen oder sich mit dem Programm MFile menügesteuert ein Makefile "zusammenklicken". Das Makefile speichert man unter dem Namen <code>Makefile</code> (ohne Endung) im selben Verzeichnis, in dem auch die Datei <code>main.c</code> mit dem Programmcode abgelegt ist. Detailliertere Erklärungen zur Funktion von Makefiles finden sich im Artikel [[AVR-GCC-Tutorial/Exkurs_Makefiles|Exkurs: Makefiles]].

<pre>
D:\beispiel>dir

Verzeichnis von D:\beispiel

28.11.2006 22:53 <DIR> .
28.11.2006 22:53 <DIR> ..
28.11.2006 20:06 118 main.c
28.11.2006 20:03 16.810 Makefile
2 Datei(en) 16.928 Bytes
</pre>

Nun gibt man ''make all'' ein. Falls das mit WinAVR installierte Programmers Notepad genutzt wird, gibt es dazu einen Menüpunkt im Tools Menü. Sind alle Einstellungen korrekt, entsteht eine Datei <code>main.hex</code>, in welcher der Code für den AVR enthalten ist.
<pre>
D:\beispiel>make all

-------- begin --------
avr-gcc (GCC) 3.4.6
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -f
unsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef
-Wa,-adhlns=obj/main.lst -std=gnu99 -Wundef -MD -MP -MF .dep/main.o.d main.c -
o obj/main.o

Linking: main.elf
avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char -funs
igned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -W
a,-adhlns=obj/main.o -std=gnu99 -Wundef -MD -MP -MF .dep/main.elf.d obj/main.o
--output main.elf -Wl,-Map=main.map,--cref -lm

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex
</pre>

Der Inhalt der hex-Datei kann nun zum Controller übertragen werden. Dies kann z. B. über In-System-Programming ([[ISP]]) erfolgen, das im [[AVR-Tutorial: Equipment]] beschrieben ist. Makefiles nach der WinAVR/MFile-Vorlage sind für die Nutzung des Programms [[AVRDUDE]] vorbereitet. Wenn man den Typ und Anschluss des Programmiergerätes richtig eingestellt hat, kann mit ''make program'' die Übertragung mittels AVRDUDE gestartet werden. Jede andere Software, die hex-Dateien lesen und zu einem AVR übertragen kann<ref>z. B. [[Pony-Prog_Tutorial|Ponyprog]], yapp, AVRStudio</ref>, kann natürlich ebenfalls genutzt werden.

Startet man nun den Controller (Reset-Taster oder Stromzufuhr aus/an), werden vom Programm die Anschlüsse PB0 und PB1 auf 1 gesetzt. Man kann mit einem Messgerät nun an diesem Anschluss die Betriebsspannung messen oder eine [[LED]] leuchten lassen (Anode an den Pin, Vorwiderstand nicht vergessen). An den Anschlüssen PB2-PB7 misst man 0 Volt. Eine mit der Anode mit einem dieser Anschlüsse verbundene LED leuchtet nicht.

= Ganzzahlige Datentypen (Integer) =

Bei der Programmierung von Mikrokontrollern ist die Definition einiger ganzzahliger Datentypen sinnvoll, an denen eindeutig die Bit-Länge abgelesen werden kann.

Standardisierte Datentypen werden in der Header-Datei <code>stdint.h</code> definiert, die folgendermaßen eingebunden werden kann:
<syntaxhighlight lang="c">#include <stdint.h></syntaxhighlight>

{| {{Tabelle}}
|+ '''int-Typen aus <code>stdint.h</code> (C99)'''  
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenbehaftete int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>int8_t</code> ||align="right"| 8 || −128 ⋯ 127 || −27 ⋯ 27−1 || <code>signed char</code>
|-
|<code>int16_t</code> ||align="right"| 16 || −32768 ⋯ 32767 || −215 ⋯ 215−1 || <code>signed short</code>, <code>signed int</code>
|-
|<code>int32_t</code> ||align="right"| 32 || −2147483648 ⋯ 2147483647 || −231 ⋯ 231−1 || <code>signed long</code>
|-
|<code>int64_t</code> ||align="right"| 64 || −9223372036854775808 ⋯ 9223372036854775807 || −263 ⋯ 263−1 || <code>signed long long</code>
|- bgcolor="#d0d0ff"
!colspan="5"| Vorzeichenlose int-Typen
|- bgcolor="#e8e8ff"
! Typname || Bit-Breite ||colspan="2"| Wertebereich
|align="center| '''C-Entsprechung''' (avr-gcc)
|-
|<code>uint8_t</code> ||align="right"| 8 || 0 ⋯ 255 || 0 ⋯ 28−1 || <code>unsigned char</code>
|-
|<code>uint16_t</code> ||align="right"| 16 || 0 ⋯ 65535 || 0 ⋯ 216−1 || <code>unsigned short</code>, <code>unsigned int</code>
|-
|<code>uint32_t</code> ||align="right"| 32 || 0 ⋯ 4294967295 || 0 ⋯ 232−1 || <code>unsigned long</code>
|-
|<code>uint64_t</code> ||align="right"| 64 || 0 ⋯ 18446744073709551615 || 0 ⋯ 264−1 || <code>unsigned long long</code>
|}

Neben den Typen gibt es auch Makros für die Bereichsgrenzen wie <code>INT8_MIN</code> oder <code>UINT16_MAX</code>. Siehe dazu auch: [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html Dokumentation der avr-libc: Standard Integer Types].

= Grundsätzlicher Programmaufbau eines µC-Programms =

Wir unterscheiden zwischen 2 verschiedenen Methoden, um ein
Mikrocontroller-Programm zu schreiben, und zwar völlig unabhängig davon, in
welcher Programmiersprache das Programm geschrieben wird.

== Sequentieller Programmablauf ==

[[Image:Sequentielle Programme.gif|left]]
Bei dieser Programmiertechnik wird eine Endlosschleife programmiert, welche im
Wesentlichen immer den gleichen Aufbau hat. Es wird hier nach dem sogenannten EVA-Prinzip gehandelt. EVA steht für "Eingabe, Verarbeitung, Ausgabe".
{{Absatz}}

== Interruptgesteuerter Programmablauf ==

[[Image:Interrupt Programme.gif|left]]
Bei dieser Methode werden beim Programmstart zuerst die gewünschten Interruptquellen aktiviert und dann in eine Endlosschleife gegangen, in welcher Dinge erledigt werden können, welche nicht zeitkritisch sind. Wenn ein Interrupt ausgelöst wird, so wird automatisch die zugeordnete Interruptfunktion ausgeführt.
{{Absatz}}

= Zugriff auf Register =

Die AVR-Controller verfügen über eine Vielzahl von Registern. Die meisten
davon sind sogenannte Schreib-/Leseregister. Das heißt, das Programm kann die
Inhalte der Register sowohl auslesen als auch beschreiben.

Register haben einen besonderen Stellenwert bei den AVR Controllern. Sie dienen dem Zugriff auf die Ports und die Schnittstellen des Controllers. Wir unterscheiden zwischen 8-Bit und 16-Bit Registern. Vorerst behandeln wir die 8-Bit Register.

Einzelne Register sind bei allen AVRs vorhanden, andere wiederum nur bei bestimmten Typen. So sind beispielsweise die Register, welche für den Zugriff auf den UART notwendig sind, selbstverständlich nur bei denjenigen Modellen vorhanden, welche über einen integrierten Hardware UART bzw. USART verfügen.

Die Namen der Register sind in den Headerdateien zu den entsprechenden AVR-Typen definiert. Dazu muss man den Namen der controllerspezifischen Headerdatei nicht kennen. Es reicht aus, die allgemeine Headerdatei ''avr/io.h'' einzubinden:

<syntaxhighlight lang="c">
#include <avr/io.h>
</syntaxhighlight>

Ist im Makefile der MCU-Typ z. B. mit dem Inhalt atmega8 definiert (und wird somit per -mmcu=atmega8 an den Compiler übergeben), wird beim Einlesen der io.h-Datei implizit ("automatisch") auch die iom8.h-Datei mit den Register-Definitionen für den ATmega8 eingelesen.


Intern wird diese "Automatik" wie folgt realisiert: Der Controllertyp wird dem Compiler als Parameter übergeben (vgl. ''avr-gcc -c -mmcu=atmega16 [...]'' im Einführungsbeispiel). Wird ein Makefile nach der WinAVR/mfile-Vorlage verwendet, setzt man die Variable ''MCU'', der Inhalt dieser Variable wird dann an passender Stelle für die Compilerparameter verwendet. Der Compiler definiert intern eine dem mmcu-Parameter zugeordnete "Variable" (genauer: ein Makro) mit dem Namen des Controllers, vorangestelltem ''__AVR_'' und angehängten Unterstrichen (z. B. wird bei ''-mmcu=atmega16'' das Makro ''__AVR_ATmega16__'' definiert). Beim Einbinden der Header-Datei ''avr/io.h'' wird geprüft, ob das jeweilige Makro definiert ist und die zum Controller passende Definitionsdatei eingelesen. Zur Veranschaulichung einige Ausschnitte aus einem Makefile:

<pre>
[...]
# MCU Type ("name") setzen:
MCU = atmega16
[...]

[...]
## Verwendung des Inhalts von MCU (hier atmega16) fuer die
## Compiler- und Assembler-Parameter
ALL_CFLAGS = -mmcu=$(MCU) -I. $(CFLAGS) $(GENDEPFLAGS)
ALL_CPPFLAGS = -mmcu=$(MCU) -I. -x c++ $(CPPFLAGS) $(GENDEPFLAGS)
ALL_ASFLAGS = -mmcu=$(MCU) -I. -x assembler-with-cpp $(ASFLAGS)
[...]

[...]
## Aufruf des Compilers:
## mit den Parametern ($(ALL_CFLAGS) ist -mmcu=$(MCU)[...] = -mmcu=atmega16[...]
$(OBJDIR)/%.o : %.c
@echo
@echo $(MSG_COMPILING) $<
$(CC) -c $(ALL_CFLAGS) $< -o $@
[...]
</pre>

Da --mmcu=atmega16 übergeben wurde, wird __AVR_ATmega16__ definiert und kann in avr/io.h zur Fallunterscheidung genutzt werden:

<syntaxhighlight lang="c">
// avr/io.h
// (bei WinAVR-Standardinstallation in C:\WinAVR\avr\include\avr)
[...]
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
// [...]
#elif defined (__AVR_ATmega16__)
// da __AVR_ATmega16__ definiert ist, wird avr/iom16.h eingebunden:
# include <avr/iom16.h>
// [...]
#else
# if !defined(__COMPILING_AVR_LIBC__)
# warning "device type not defined"
# endif
#endif
</syntaxhighlight>

Die Beispiele in den folgenden Abschnitten demonstrieren den Zugriff auf Register anhand der Register für I/O-Ports (PORTx, DDRx, PINx), die Vorgehensweise ist jedoch für alle Register (z. B. die des UART, ADC, SPI) analog.

== Schreiben in Register ==

Zum Schreiben kann man Register einfach wie eine Variable setzen.<ref>In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Schreibzugriff über die Funktion outp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt, outp() ist nicht mehr erforderlich.</ref>

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main()
{
/* Setzt das Richtungsregister des Ports A auf 0xff
(alle Pins als Ausgang, vgl. Abschnitt Zugriff auf Ports): */
DDRA = 0xff;

/* Setzt PortA auf 0x03, Bit 0 und 1 "high", restliche "low": */
PORTA = 0x03;

// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
DDRB = 0x1F; /* direkte Zuweisung - unübersichtlich */

/* Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
aber übersichtlicher und selbsterklärend: */
DDRB = (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);

while (1);
}
</syntaxhighlight>

Die ausführliche Schreibweise sollte bevorzugt verwendet werden, da dadurch die Zuweisungen selbsterklärend sind und somit der Code leichter nachvollzogen werden kann. Atmel verwendet sie auch bei Beispielen in Datenblätten und in den allermeisten Quellcodes zu Application-Notes. Mehr zu der Schreibweise mit "|" und "<<" findet man unter [[Bitmanipulation]].

Der gcc C-Compiler unterstützt ab Version 4.3.0 Konstanten im Binärformat, z. B. DDRB = 0b00011111. Diese Schreibweise ist jedoch nur in GNU-C verfügbar und nicht in ISO-C definiert. Man sollte sie daher nicht verwenden, wenn Code mit anderen ausgetauscht oder mit anderen Compilern bzw. älteren Versionen des gcc genutzt werden soll.

== Verändern von Registerinhalten ==

Einzelne Bits setzt und löscht man "Standard-C-konform" mittels logischer (Bit-) Operationen.

<syntaxhighlight lang="c">
x |= (1 << Bitnummer); // Hiermit wird ein Bit in x gesetzt
x &= ~(1 << Bitnummer); // Hiermit wird ein Bit in x geloescht
</syntaxhighlight>

Es wird jeweils nur der Zustand des angegebenen Bits geändert, der vorherige Zustand der anderen Bits bleibt erhalten.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
#define MEINBIT 2
...
PORTA |= (1 << MEINBIT); /* setzt Bit 2 an PortA auf 1 */
PORTA &= ~(1 << MEINBIT); /* loescht Bit 2 an PortA */
</syntaxhighlight>

Mit dieser Methode lassen sich auch mehrere Bits eines Registers gleichzeitig setzen und löschen.

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRA &= ~( (1<<PA0) | (1<<PA3) ); /* PA0 und PA3 als Eingaenge */
PORTA |= ( (1<<PA0) | (1<<PA3) ); /* Interne Pull-Up fuer beide einschalten */
</syntaxhighlight>

Bei bestimmten AVR Registern mit Bits, die durch Beschreiben mit einer logischen 1 gelöscht werden, muss eine absolute Zuweisung benutzt werden. Ein ODER löscht in diesen Registern ALLE gesetzten Bits!

Beispiel:
<syntaxhighlight lang="c">
#include <avr/io.h>
...
TIFR2 = (1<<OCF2A); // Nur Bit OCF2A löschen
</syntaxhighlight>

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind nicht mehr erforderlich.

Siehe auch:
* [[Bitmanipulation]]
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers

== Lesen aus Registern ==

Zum Lesen kann man auf Register einfach wie auf eine Variable zugreifen. In Quellcodes, die für ältere Versionen des avr-gcc/der avr-libc entwickelt wurden, erfolgt der Lesezugriff über die Funktion inp(). Aktuelle Versionen des Compilers unterstützen den Zugriff nun direkt und inp() ist nicht mehr erforderlich.

Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>

uint8_t foo;

//...

int main(void)
{
/* kopiert den Status der Eingabepins an PortB
in die Variable foo: */
foo = PINB;
//...
}
</syntaxhighlight>

Die Abfrage der Zustände von Bits erfolgt durch Einlesen des gesamten Registerinhalts und ausblenden der Bits deren Zustand nicht von Interesse ist. Einige Beispiele zum Prüfen ob Bits gesetzt oder gelöscht sind:

<syntaxhighlight lang="c">
#define MEINBIT0 0
#define MEINBIT2 2

uint8_t i;

extern test1();

// Funkion test1 aufrufen, wenn Bit 0 in Register PINA gesetzt (1) ist
i = PINA; // Inhalt in Arbeitsvariable
i = i & 0x01; // alle Bits bis auf Bit 0 ausblenden (bitweise und)
// falls das Bit gesetzt war, hat i den Inhalt 1
if ( i != 0 ) { // Ergebnis ungleich 0 (wahr)?
test1(); // dann muss Bit 0 in i gesetzt sein -> Funktion aufrufen
}
// verkürzt:
if ( ( PINA & 0x01 ) != 0 ) {
test1();
}
// nochmals verkürzt:
if ( PINA & 0x01 ) {
test1();
}
// mit definierter Bitnummer:
if ( PINA & ( 1 << MEINBIT0 ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und/oder Bit 2 gesetzt ist. (Bit 0 und 2 also Wert 5)
// (Bedenke: Bit 0 hat Wert 1, Bit 1 hat Wert 2 und Bit 2 hat Wert 4)
if ( PINA & 0x05 ) {
test1(); // Vergleich <> 0 (wahr), also mindestens eines der Bits gesetzt
}
// mit definierten Bitnummern:
if ( PINA & ( ( 1 << MEINBIT0 ) | ( 1 << MEINBIT2 ) ) ) {
test1();
}

// Funktion aufrufen, wenn Bit 0 und Bit 2 gesetzt sind
if ( ( PINA & 0x05 ) == 0x05 ) { // nur wahr, wenn beide Bits gesetzt
test1();
}

// Funktion test2() aufrufen, wenn Bit 0 gelöscht (0) ist
i = PINA; // einlesen in temporäre Variable
i = i & 0x01; // maskieren von Bit 0
if ( i == 0 ) { // Vergleich ist wahr, wenn Bit 0 nicht gesetzt ist
test2();
}
// analog mit not-Operator
if ( !i ) {
test2();
}
// nochmals verkürzt:
if ( !( PINA & 0x01 ) ) {
test2();
}
</syntaxhighlight>

== Warten auf einen bestimmten Zustand ==

Es gibt in der Bibliothek avr-libc Funktionen, die warten, bis ein bestimmter Zustand eines Bits erreicht ist. Es ist allerdings normalerweise eine eher unschöne Programmiertechnik, da in diesen Funktionen "blockierend" gewartet wird. Der Programmablauf bleibt also an dieser Stelle stehen, bis das maskierte Ereignis erfolgt ist. Setzt man den [[Watchdog]] ein, muss man darauf achten, dass dieser auch noch getriggert wird (Zurücksetzen des Watchdogtimers).

Die Funktion '''loop_until_bit_is_set''' wartet in einer Schleife, bis das definierte Bit gesetzt ist. Wenn das Bit beim Aufruf der Funktion bereits gesetzt ist, wird die Funktion sofort wieder verlassen. Das niederwertigste Bit hat die Bitnummer 0.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 2 (das dritte Bit) in Register PINA gesetzt (1) ist */

#define WARTEPIN PINA
#define WARTEBIT PA2

// mit der avr-libc Funktion:
loop_until_bit_is_set(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// _nicht_ ungleich 0 (also 0) ist.
while ( !(WARTEPIN & (1 << WARTEBIT)) ) {}
...
</syntaxhighlight>

Die Funktion '''loop_until_bit_is_clear''' wartet in einer Schleife, bis das definierte Bit gelöscht ist. Wenn das Bit beim Aufruf der Funktion bereits gelöscht ist, wird die Funktion sofort wieder verlassen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...

/* Warten bis Bit Nr. 4 (das fuenfte Bit) in Register PINB geloescht (0) ist */
#define WARTEPIN PINB
#define WARTEBIT PB4

// avr-libc-Funktion:
loop_until_bit_is_clear(WARTEPIN, WARTEBIT);

// dito in "C-Standard":
// Durchlaufe die (leere) Schleife solange das WARTEBIT in Register WARTEPIN
// gesetzt (1) ist
while ( WARTEPIN & (1<<WARTEBIT) ) {}
...
</syntaxhighlight>

Universeller und auch auf andere Plattformen besser übertragbar ist die Verwendung von C-Standardoperationen.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Special Function Registers
* [[Bitmanipulation]]

== 16-Bit Register (ADC, ICR1, OCR1x, TCNT1, UBRR) ==

Einige der Portregister in den AVR-Controllern sind 16 Bit breit. Im Datenblatt sind diese Register üblicherweise mit dem Suffix "L" (Low-Byte) und "H" (High-Byte) versehen. Die avr-libc definiert zusätzlich die meisten dieser Variablen die Bezeichnung ohne "L" oder "H". Auf diese Register kann dann direkt zugegriffen werden. Dies ist zum Beispiel der Fall für Register wie ADC oder TCNT1.
<syntaxhighlight lang="c">
#include <avr/io.h>
...
uint16_t foo;

/* setzt die Wort-Variable foo auf den Wert der letzten AD-Wandlung */
foo = ADC;
</syntaxhighlight>

Bei anderen Registern, wie zum Beispiel Baudraten-Register, liegen High- und Low-Teil nicht direkt nebeneinander im SFR-Bereich, so dass ein 16-Bit Zugriff nicht möglich ist und der Zugriff zusammengebastelt werden muss:

<syntaxhighlight lang="c">
#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

...
uint16_t baud = F_CPU / (UART_BAUD_RATE * 16L) -1;

UBRRH = (uint8_t) (baud >> 8);
UBRRL = (uint8_t) baud;
...
</syntaxhighlight>

Bei einigen AVR-Typen wie ATmega8 oder ATmega16 teilen sich UBRRH und UCSRC die gleiche Speicher-Adresse. Damit der AVR trotzdem zwischen den beiden Registern unterscheiden kann, bestimmt das Bit7 (URSEL), welches Register tatsächlich beschrieben werden soll. ''1000 0011'' (0x83) adressiert demnach UCSRC und übergibt den Wert ''3''. Und ''0000 0011'' (0x3) adressiert UBRRH und übergibt ebenfalls den Wert ''3''.

Speziell bei den 16-Bit-Timern und auch beim ADC ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z. B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann.

Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.

Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem ''Lesezugriff'' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.
* Bei einem ''Schreibzugriff'' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.

Das bedeutet für die Reihenfolge:
* Lesezugriff: Erst Low-Byte, dann High-Byte
* Schreibzugriff: Erst High-Byte, dann Low-Byte

Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. 16-Bit-Zugriffe sind generell nicht atomar! Wenn mit Interrupts gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.

Beim ADC-Datenregister ADCH/ADCL ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!

Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!

In beiden Fällen – also sowohl bei den Timern als auch beim ADC – werden vom C-Compiler 16-Bit Pseudo-Register zur Verfügung gestellt (z. B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden! Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.

Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.

Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.

ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt.

Im Umgang mit 16-Bit Registern siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Related Pages/Frequently Asked Questions/Nr. 8
* Datenblatt Abschnitt ''Accessing 16-bit Registers''

== IO-Register als Parameter und Variablen ==

Um Register als Parameter für eigene Funktionen übergeben zu können, muss man sie als einen volatile uint8_t Pointer übergeben. Zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <util/delay.h>

uint8_t key_pressed (volatile uint8_t *inputreg, uint8_t inputbit)
{
static uint8_t last_state = 0;

if (last_state == (*inputreg & (1<<inputbit)))
return 0; /* keine Änderung */

/* Wenn doch, warten bis etwaiges Prellen vorbei ist: */
_delay_ms(20);

/* Zustand für nächsten Aufruf merken: */
last_state = *inputreg & (1<<inputbit);

/* und den entprellten Tastendruck zurückgeben: */
return *inputreg & (1<<inputbit);
}

/* Beispiel für einen Funktionsaufruf: */

void foo (void)
{
uint8_t i = key_pressed (&PINB, PB1);
}
</syntaxhighlight>

Ein Aufruf der Funktion mit call by value würde Folgendes bewirken: Beim Funktionseintritt wird nur eine Kopie des momentanen Portzustandes angefertigt, die sich unabhängig vom tatsächlichen Zustand das Ports nicht mehr ändert, womit die Funktion wirkungslos wäre. Die Übergabe eines Zeigers wäre die Lösung, wenn der Compiler nicht optimieren würde. Denn dadurch wird im Programm nicht von der Hardware gelesen, sondern wieder nur von einem Abbild im Speicher. Das Ergebnis wäre das gleiche wie oben. Mit dem Schlüsselwort volatile sagt man nun dem Compiler, dass die entsprechende Variable entweder durch andere Softwareroutinen (Interrupts) oder durch die Hardware verändert werden kann.

Siehe auch: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass avr-libc FAQ: "How do I pass an IO port as a parameter to a function?"]

= Zugriff auf IO-Ports =

Jeder AVR implementiert eine unterschiedliche Menge an GPIO-Registern
(GPIO - General Purpose Input/Output). Diese Register dienen dazu:
* einzustellen welche der Anschlüsse ("Beinchen") des Controllers als Ein- oder Ausgänge dienen
* bei Ausgängen deren Zustand festzulegen
* bei Eingängen deren Zustand zu erfassen

Mittels GPIO werden digitale Zustände gesetzt und erfasst, d.h. die Spannung an einem Ausgang wird ein- oder ausgeschaltet und an einem Eingang wird erfasst, ob die anliegende Spannung über oder unter einem bestimmten Schwellwert liegt. Im Datenblatt Abschnitt Electrical Characteristics/DC Characteristics finden sich die Spannungswerte (V_OL, V_OH für Ausgänge, V_IL, V_IH für Eingänge).

Die Verarbeitung von analogen Eingangswerten und die Ausgabe von Analogwerten wird in Kapitel [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|Analoge Ein- und Ausgabe]] behandelt.

Die physischen Ein- und Ausgänge werden bei AVR-Controllern zu logischen Ports gruppiert.

Alle Ports werden über Register gesteuert. Dazu sind jedem Port 3 Register zugeordnet:

{| class="wikitable"
|-
! DDRx
| Datenrichtungsregister für Port'''x'''.
'''x''' entspricht '''A''', '''B''', ''' C''', '''D''' usw. (abhängig von der Anzahl der Ports des verwendeten AVR). Bit im Register gesetzt (1) für Ausgang, Bit gelöscht (0) für Eingang.
|-
! PINx
| Eingangsadresse für Port'''x'''.
Zustand des Ports. Die Bits in PINx entsprechen dem Zustand der als Eingang definierten Portpins. Bit 1 wenn Pin "high", Bit 0 wenn Portpin low.
|-
! PORTx
| Datenregister für Port'''x'''.
Dieses Register wird verwendet, um die Ausgänge eines Ports anzusteuern. Bei Pins, die mittels DDRx auf Eingang geschaltet wurden, können über PORTx
die internen Pull-Up Widerstände aktiviert oder deaktiviert werden (1 = aktiv).
|}

Die folgenden Beispiele gehen von einem AVR aus, der sowohl Port A als auch Port B besitzt. Sie müssen für andere AVRs (zum Beispiel ATmega8/48/88/168) entsprechend angepasst werden.

== Datenrichtung bestimmen ==

Zuerst muss die Datenrichtung der verwendeten Pins bestimmt werden. Um dies zu erreichen, wird das Datenrichtungsregister des entsprechenden Ports beschrieben.

Für jeden Pin, der als Ausgang verwendet werden soll, muss dabei das
entsprechende Bit auf dem Port gesetzt werden. Soll der Pin als Eingang
verwendet werden, muss das entsprechende Bit gelöscht sein.

Beispiel:
Angenommen am Port B sollen die Pins 0 bis 4 als Ausgänge definiert werden, die noch verbleibenden Pins 5 bis 7 sollen als Eingänge fungieren. Dazu ist es daher notwendig, im für das Port B zuständigen Datenrichtungsregister DDRB folgende Bitkonfiguration einzutragen

+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |

In C liest sich das dann so:

<syntaxhighlight lang="c">
// in io.h wird u.a. DDRB definiert:
#include <avr/io.h>

int main()
{
// Setzen der Bits 0,1,2,3 und 4
// Binär 00011111 = Hexadezimal 1F
// direkte Zuweisung - standardkonform */
DDRB = 0x1F; /*

// übersichtliche Alternative - Binärschreibweise, aber kein ISO-C
DDRB = 0b00011111;

// Ausführliche Schreibweise: identische Funktionalität, mehr Tipparbeit
// aber übersichtlicher und selbsterklärend:
DDRB |= (1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3) | (1 << DDB4);
</syntaxhighlight>

Die Pins 5 bis 7 werden (da 0) als Eingänge geschaltet. Weitere Beispiele:

<syntaxhighlight lang="c">
// Alle Pins des Ports B als Ausgang definieren:
DDRB = 0xff;
// Pin0 wieder auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~(1 << DDB0);
// Pin 3 und 4 auf Eingang und andere im ursprünglichen Zustand belassen:
DDRB &= ~((1 << DDB3) | (1 << DDB4));
// Pin 0 und 3 wieder auf Ausgang und andere im ursprünglichen Zustand belassen:
DDRB |= (1 << DDB0) | (1 << DDB3);
// Alle Pins auf Eingang:
DDRB = 0x00;
</syntaxhighlight>

== Vordefinierte Bitnummern für I/O-Register ==

Die Bitnummern (z. B. PCx, PINCx und DDCx für den Port C) sind in den io*.h-Dateien der avr-libc definiert und dienen lediglich der besseren Lesbarkeit. Man muss diese Definitionen nicht verwenden oder kann auch einfach "immer" PAx, PBx, PCx usw. nutzen, auch wenn der Zugriff auf Bits in DDRx- oder PINx-Registern erfolgt. Für den Compiler sind die Ausdrücke (1<<PC7), (1<<DDC7) und (1<<PINC7) identisch zu (1<<7) (genauer: der Präprozessor ersetzt die Ausdrücke (1<<PC7),... zu (1<<7)). Ein Ausschnitt der Definitionen für Port C eines ATmega32 aus der iom32.h-Datei zur Verdeutlichung (analog für die weiteren Ports):

<syntaxhighlight lang="c">
...
/* PORTC */
#define PC7 7
#define PC6 6
#define PC5 5
#define PC4 4
#define PC3 3
#define PC2 2
#define PC1 1
#define PC0 0

/* DDRC */
#define DDC7 7
#define DDC6 6
#define DDC5 5
#define DDC4 4
#define DDC3 3
#define DDC2 2
#define DDC1 1
#define DDC0 0

/* PINC */
#define PINC7 7
#define PINC6 6
#define PINC5 5
#define PINC4 4
#define PINC3 3
#define PINC2 2
#define PINC1 1
#define PINC0 0
</syntaxhighlight>

== Digitale Signale ==

Am einfachsten ist es, digitale Signale mit dem Mikrocontroller zu erfassen bzw. auszugeben.

== Ausgänge ==
Will man als Ausgang definierte Pins (entsprechende DDRx-Bits = 1) auf Logisch 1 setzen, setzt man die entsprechenden Bits im Portregister.

Mit dem Befehl
<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = 0x04; /* besser PORTB=(1<<PB2) */

// übersichtliche Alternative - Binärschreibweise
PORTB = 0b00000100; /* direkte Zuweisung - übersichtlich */

</syntaxhighlight>
wird also der Ausgang an Pin PB2 gesetzt (Beachte, dass die Bits immer ''von 0 an'' gezählt werden, das niederwertigste Bit ist also Bitnummer 0 und nicht etwa Bitnummer 1).

Man beachte, dass bei der Zuweisung mittels '''=''' immer alle Pins gleichzeitig angegeben werden. Man sollte also, wenn nur bestimmte Ausgänge geschaltet werden sollen, zuerst den aktuellen Wert des Ports einlesen und das Bit des gewünschten Ports in diesen Wert einfließen lassen. Will man also nur den dritten Pin (Bit Nr. 2) an Port B auf "high" setzen und den Status der anderen Ausgänge unverändert lassen, nutze man diese Form:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB = PORTB | 0x04; /* besser: PORTB = PORTB | ( 1<<PB2 ) */
/* vereinfacht durch Nutzung des |= Operators : */
PORTB |= (1<<PB2);

/* auch mehrere "gleichzeitig": */
PORTB |= (1<<PB4) | (1<<PB5); /* Pins PB4 und PB5 "high" */
</syntaxhighlight>

"Ausschalten", also Ausgänge auf "low" setzen, erfolgt analog:

<syntaxhighlight lang="c">
#include <avr/io.h>
...
PORTB &= ~(1<<PB2); /* löscht Bit 2 in PORTB und setzt damit Pin PB2 auf low */
PORTB &= ~( (1<<PB4) | (1<<PB5) ); /* Pin PB4 und Pin PB5 "low" */
</syntaxhighlight>
Siehe auch [[Bitmanipulation]]

In Quellcodes, die für ältere Version den des avr-gcc/der avr-libc entwickelt wurden, werden einzelne Bits mittels der Funktionen sbi und cbi gesetzt bzw. gelöscht. Beide Funktionen sind in aktuellen Versionen der avr-libc nicht mehr enthalten und auch nicht mehr erforderlich.

''Falls der Anfangszustand von Ausgängen kritisch ist, muss die Reihenfolge beachtet werden, mit der die Datenrichtung (DDRx) eingestellt und der Ausgabewert (PORTx) gesetzt wird:''

Für Ausgangspins, die mit Anfangswert "high" initialisiert werden sollen:
* zuerst die Bits im PORTx-Register setzen
* anschließend die Datenrichtung auf Ausgang stellen

Daraus ergibt sich die Abfolge für einen Pin, der bisher als Eingang mit abgeschaltetem Pull-Up konfiguriert war:
* setze PORTx: interner Pull-Up aktiv
* setze DDRx: Ausgang ("high")

Bei der Reihenfolge erst DDRx und dann PORTx kann es zu einem kurzen "low-Puls" kommen, der auch externe Pull-Up-Widerstände "überstimmt". Die (ungünstige) Abfolge: Eingang -> setze DDRx: Ausgang (auf "low", da PORTx nach Reset 0) -> setze PORTx: Ausgang auf high. Vergleiche dazu auch das Datenblatt Abschnitt ''Configuring the Pin''.

== Eingänge (Wie kommen Signale in den µC) ==

Die digitalen Eingangssignale können auf verschiedene Arten zu unserer Logik gelangen.

=== Signalkopplung ===

Am einfachsten ist es, wenn die Signale direkt aus einer anderen digitalen Schaltung übernommen werden können. Hat der Ausgang der entsprechenden Schaltung TTL-Pegel dann können wir sogar direkt den Ausgang der Schaltung mit einem Eingangspin von unserem Controller verbinden.

Hat der Ausgang der anderen Schaltung keinen TTL-Pegel so müssen wir den Pegel über entsprechende Hardware (z. B. Optokoppler, [[Widerstand#Spannungsteiler|Spannungsteiler]], "Levelshifter" aka [[Pegelwandler]]) anpassen.

Die Masse der beiden Schaltungen muss selbstverständlich miteinander verbunden werden. Der Software selber ist es natürlich letztendlich egal, wie das Signal eingespeist wird. Wir können ja ohnehin lediglich prüfen, ob an einem Pin unseres Controllers eine logische 1 (Spannung größer ca. 0,7*Vcc) oder eine logische 0 (Spannung kleiner ca. 0,2*Vcc) anliegt. Detaillierte Informationen darüber, ab welcher Spannung ein Eingang als 0 ("low") bzw. 1 ("high") erkannt wird, liefert die Tabelle DC Characteristics im Datenblatt des genutzten Controllers.

{| class="wikitable" style="text-align:center"
|+ '''Spannungstabelle''' (ca. Grenzwerte)
|
! Low || High
|-
! bei 5 V
| 1 V || 3,5 V
|-
! bei 3,3 V
| 0,66 V || 2,31 V
|-
! bei 1,8 V
| 0,36 V || 1,26 V
|}

Die Abfrage der Zustände der Portpins erfolgt direkt über den Registernamen.

{{Warnung|Dabei ist wichtig, zur Abfrage der Eingänge ''nicht'' etwa Portregister '''PORTx''' zu verwenden, sondern Eingangsregister '''PINx'''. Ansonsten liest man nicht den Zustand der Eingänge, sondern den Status der internen Pull-Up-Widerstände. Die Abfrage der Pinzustände über PORTx statt PINx ist ein häufiger Fehler beim AVR-"Erstkontakt".}}

Will man also die aktuellen Signalzustände von Port D abfragen und in eine Variable namens bPortD abspeichern, schreibt man folgende Befehlszeilen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdint.h>
...
uint8_t bPortD;
...
bPortD = PIND;
...
</syntaxhighlight>

Mit den C-Bitoperationen kann man den Status der Bits abfragen.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
/* Fuehre Aktion aus, wenn Bit Nr. 1 (das "zweite" Bit) in PINC gesetzt (1) ist */
if ( PINC & (1<<PINC1) ) {
/* Aktion */
}

/* Fuehre Aktion aus, wenn Bit Nr. 2 (das "dritte" Bit) in PINB geloescht (0) ist */
if ( !(PINB & (1<<PINB2)) ) {
/* Aktion */
}
...
</syntaxhighlight>
Siehe auch [[Bitmanipulation#Bits_prüfen]]

=== Interne Pull-Up Widerstände ===

Portpins für Ein- und Ausgänge (GPIO) eines AVR verfügen über zuschaltbare interne Pull-Up Widerstände (nominal mehrere 10kOhm, z. B. ATmega16 20-50kOhm). Diese können in vielen Fällen statt externer Widerstände genutzt werden.

Die internen Pull-Up Widerstände von Vcc zu den einzelnen Portpins werden über das Register ''' PORTx''' aktiviert bzw. deaktiviert, wenn ein Pin als ''' Eingang''' geschaltet ist.

Wird der Wert des entsprechenden Portpins auf 1 gesetzt, so ist der Pull-Up Widerstand aktiviert. Bei einem Wert von 0 ist der Pull-Up Widerstand nicht aktiv. Man sollte jeweils entweder den internen oder einen externen Pull-Up Widerstand verwenden, aber nicht beide zusammen.

Im Beispiel werden alle Pins des Ports D als Eingänge geschaltet und alle Pull-Up Widerstände aktiviert. Weiterhin wird Pin PC7 als Eingang geschaltet und dessen interner Pull-Up Widerstand aktiviert, ohne die Einstellungen für die anderen Portpins (PC0-PC6) zu verändern.

<syntaxhighlight lang="c">
#include <avr/io.h>
...
DDRD = 0x00; /* alle Pins von Port D als Eingang */
PORTD = 0xff; /* interne Pull-Ups an allen Port-Pins aktivieren */
...
DDRC &= ~(1<<PC7); /* Pin PC7 als Eingang */
PORTC |= (1<<PC7); /* internen Pull-Up an PC7 aktivieren */
</syntaxhighlight>

=== Taster und Schalter ===

Der Anschluss mechanischer Kontakte an den Mikrocontroller, ist zwischen zwei unterschiedliche Methoden zu unterscheiden: ''Active Low'' und ''Active High''.

<gallery widths="300" heights="300" caption="Anschluss mechanischer Kontakte an einen µC">
Image:Active Low.gif|'''Active Low:''' Bei dieser Methode wird der Kontakt zwischen den Eingangspin des Controllers und Masse geschaltet. Damit bei offenem Schalter der Controller kein undefiniertes Signal bekommt, wird zwischen die Versorgungsspannung und den Eingangspin ein sogenannter '''Pull-Up''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffnetem Schalter auf logisch 1 zu ziehen.
Image:Active High.gif|'''Active High:''' Hier wird der Kontakt zwischen die Versorgungsspannung und den Eingangspin geschaltet. Damit bei offener Schalterstellung kein undefiniertes Signal am Controller ansteht, wird zwischen den Eingangspin und die Masse ein '''Pull-Down''' Widerstand geschaltet. Dieser dient dazu, den Pegel bei geöffneter Schalterstellung auf logisch 0 zu halten.
</gallery>

Der Widerstandswert von Pull-Up- und Pull-Down-Widerständen ist an sich nicht kritisch. Wird er allerdings zu hoch gewählt, ist die Wirkung eventuell nicht gegeben. Als üblicher Wert haben sich 10 kOhm eingebürgert. Die AVRs verfügen an den meisten Pins über zuschaltbare interne Pull-Up Widerstände (vgl. Abschnitt [[AVR-GCC-Tutorial#Interne Pull-Up Widerstände|Interne Pull-Up Widerstände]]), welche insbesondere wie hier bei Tastern und ähnlichen Bauteilen (z. B. Drehgebern) statt externer Bauteile verwendet werden können. Interne Pull-Down-Widerstand sind nicht verfügbar und müssen daher in Form zusätzlicher Bauteile in die Schaltung eingefügt werden.

==== Taster entprellen ====

Siehe: ''[[Entprellung#Warteschleifen-Verfahren|Entprellung: Warteschleifen-Verfahren]]

= Warteschleifen (delay.h) =

Der Programmablauf kann verschiedene Arten von Wartefunktionen erfordern:

* Warten im Sinn von Zeitvertrödeln
* Warten auf einen bestimmten Zustand an den I/O-Pins
* Warten auf einen bestimmten Zeitpunkt (siehe Timer)
* Warten auf einen bestimmten Zählerstand (siehe Counter)

Der einfachste Fall, das Zeitvertrödeln, kann in vielen Fällen und mit großer Genauigkeit anhand der avr-libc Bibliotheksfunktionen _delay_ms() und _delay_us() erledigt werden. Die Bibliotheksfunktionen sind einfachen Zählschleifen (Warteschleifen) vorzuziehen, da leere Zählschleifen ohne besondere Vorkehrungen sonst bei eingeschalteter Optimierung vom avr-gcc-Compiler wegoptimiert werden. Weiterhin sind die Bibliotheksfunktionen bereits darauf vorbereitet, die in F_CPU definierte Taktfrequenz zu verwenden. Außerdem sind die Funktionen der Bibliothek wirklich getestet.

Einfach!? Schon, aber während gewartet wird, macht der µC nichts anderes mehr (abgesehen von möglicherweise auftretenden Interrupts, falls welche aktiviert sind). Die Wartefunktion blockiert den Programmablauf. Möchte man einerseits warten, um z. B. eine LED blinken zu lassen und gleichzeitig andere Aktionen ausführen z. B. weitere LED bedienen, sollten die Timer/Counter des AVR verwendet werden.

Die Bibliotheksfunktionen funktionieren allerdings nur dann korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten konstanten Werten aufgerufen werden. Der Quellcode muss mit eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel Maschinencode erzeugt, und die Wartezeiten stimmen nicht mehr mit dem Parameter überein.

Eine weitere Einschränkung liegt darin, daß sie möglicherweise länger warten, als erwartet, nämlich in dem Fall, daß Interrupts auftreten und die _delay...()-Funktion unterbrechen. Genau genommen warten diese nämlich nicht eine bestimmte Zeit, sondern verbrauchen eine bestimmte Anzahl von Prozessortakten. Die wiederum ist so bemessen, daß ohne Unterbrechung durch Interrupts die gewünschte Wartezeit erreicht wird.
Wird das Warten aber durch eine oder mehrere ISR unterbrochen, die zusammen 1% Prozessorzeit verbrauchen, dann dauert das Warten etwa 1% länger. Bei 50% Last durch die ISR dauert das Warten doppelt solange wie gewünscht, bei 90% zehnmal solange...

Abhängig von der Version der Bibliothek verhalten sich die Bibliotheksfunktionen etwas unterschiedlich.

== avr-libc Versionen bis 1.6 ==

Die Wartezeit der Funktion _delay_ms() ist auf 262,14ms/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 13,1ms warten. Die Wartezeit der Funktion _delay_us() ist auf 768us/F_CPU (in MHz) begrenzt, d.h. bei 20 MHz kann man nur max. 38,4µs warten. Längere Wartezeiten müssen dann über einen mehrfachen Aufruf in einer Schleife gelöst werden.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z. B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* in älteren avr-libc Versionen <avr/delay.h> */

/*
lange, variable Verzögerungszeit, Einheit in Millisekunden

Die maximale Zeit pro Funktionsaufruf ist begrenzt auf
262.14 ms / F_CPU in MHz (im Beispiel:
262.1 / 3.6864 = max. 71 ms)

Daher wird die kleine Warteschleife mehrfach aufgerufen,
um auf eine längere Wartezeit zu kommen. Die zusätzliche
Prüfung der Schleifenbedingung lässt die Wartezeit geringfügig
ungenau werden (macht hier vielleicht 2-3ms aus).
*/

void long_delay(uint16_t ms)
{
for(; ms>0; ms--) _delay_ms(1);
}

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) // Endlosschleife
{
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z. B. angeschlossene LED
long_delay(1000); // Eine Sekunde warten...
}

return 0;
}
</syntaxhighlight>

== avr-libc Versionen ab 1.7 ==

_delay_ms() kann mit einem Argument bis 6553,5 ms (= 6,5535 Sekunden) benutzt werden. Es ist nicht möglich, eine Variable als Argument zu übergeben. Wird die früher gültige Grenze von 262,14 ms/F_CPU (in MHz) überschritten, so arbeitet _delay_ms() einfach etwas ungenauer und zählt nur noch mit einer Auflösung von 1/10 ms. Eine Verzögerung von 1000,10 ms ließe sich nicht mehr von einer von 1000,19 ms unterscheiden. Ein Verlust, der sich im Allgemeinen verschmerzen lässt. Dem Programmierer wird keine Rückmeldung gegeben, dass die Funktion ggf. gröber arbeitet, d.h. wenn es darauf ankommt, bitte den Parameter wie bisher geschickt wählen.

Die Funktion _delay_us() wurde ebenfalls erweitert. Wenn deren maximal als genau behandelbares Argument überschritten wird, benutzt diese intern _delay_ms(). Damit gelten in diesem Fall die _delay_ms() Einschränkungen.

Beispiel: Blinken einer LED an PORTB Pin PB0 im ca. 1s Rhythmus, avr-libc ab Version 1.6
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
/* Definiere F_CPU, wenn F_CPU nicht bereits vorher definiert
(z.B. durch Übergabe als Parameter zum Compiler innerhalb
des Makefiles). Zusätzlich Ausgabe einer Warnung, die auf die
"nachträgliche" Definition hinweist */
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

int main( void )
{
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
_delay_ms(1000); // Eine Sekunde +/-1/10000 Sekunde warten...
// funktioniert nicht mit Bibliotheken vor 1.6

}
return 0;
}
</syntaxhighlight>

Trick zur Übergabe einer Variablen an _delay_ms():
<syntaxhighlight lang="c">
#include <avr/io.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h>

void sleep ( uint8_t ms )
{
for(; ms > 0; ms--) _delay_ms(1);
}

int main( void )
{
int x = 0; // Variable als Wartezeit erstellen
DDRB = ( 1 << PB0 ); // PB0 an PORTB als Ausgang setzen

while( 1 ) { // Endlosschleife
PORTB ^= ( 1 << PB0 ); // Toggle PB0 z.B. angeschlossene LED
sleep(x);
x++;
}
return 0;
}
</syntaxhighlight>

Die _delay_ms() und die _delay_us aus '''avr-libc 1.7.0''' sind fehlerhaft. _delay_ms () läuft 4x schneller als erwartet. Abhilfe ist eine korrigierte Includedatei: [http://www.mikrocontroller.net/topic/196738#1943039]

= Programmieren mit Interrupts =

<div style="float:right; margin:2em;">
[[Image:Interrupt Programme.gif]]
</div>
Nachdem wir nun alles Wissenswerte für die serielle Programmerstellung
gelernt haben nehmen wir jetzt ein völlig anderes Thema in Angriff, nämlich
die Programmierung unter Zuhilfenahme der Interrupts des AVR.

Tritt ein Interrupt auf, unterbricht (engl. interrupts) der Controller die Verarbeitung des Hauptprogramms und verzweigt zu einer Interruptroutine. Das Hauptprogramm wird also beim Eintreffen eines Interrupts unterbrochen, die Interruptroutine ausgeführt und danach erst wieder das Hauptprogramm an der Unterbrechungsstelle fortgesetzt (vgl. die Abbildung).

Um Interrupts verarbeiten zu können, ist folgendes zu beachten:

* Für jede aktivierte Interruptquelle ist eine Funktion zu programmieren, in der die beim Auftreten des jeweiligen Interrupts erforderlichen Verarbeitungsschritte enthalten sind. Für diese Funktion existieren verschiedene Bezeichnungen. Üblich sind die englischen Begriffe Interrupt-Handler oder Interrupt-Service-Routinen (ISR), man findet aber auch die Bezeichnungen Interruptverarbeitungs- oder -behandlungsroutine oder auch kurz Interruptroutine. Zum Beispiel wird üblicherweise in der ISR zur Verarbeitung des Empfangsinterrupts eines UARTs (UART-RX Interrupt) das empfangene Zeichen in einen Zwischenspeicher (FIFO-Buffer) kopiert, dessen Inhalt später von anderen Programmteilen geleert wird. Sofern der Zwischenspeicher ausreichend groß ist, geht also kein Zeichen verloren, auch wenn im Hauptprogramm zeitintensive Operationen durchgeführt werden.
* Die benötigten Interrupts sind in den jeweiligen Funktionsbausteinen einzuschalten. Dies erfolgt über das jeweilige Aktivierungsbit (Interrupt Enable) in einem der Hardwareregister (z.B. RX(Complete)Interrupt Enable eines UARTs)
* Sämtliche Interrupts werden über einen weiteren globalen Schalter aktiviert und deaktiviert. Zur Verarbeitung der Interrupts ist dieser Schalter zu aktivieren (sei(), siehe unten).

Alle Punkte sind zu beachten. Fehlt z.B. die globale Aktivierung, werden Interruptroutinen auch dann nicht aufgerufen, wenn sie im Funktionsbaustein eingeschaltet sind und eine Behandlungsroutine verhanden ist.

Siehe auch

* [http://www.mikrocontroller.net/forum/read-1-235092.html#new Ausführlicher Thread im Forum]
* Artikel [[Interrupt]]
* Artikel [[Multitasking]]
{{Clear}}

== Anforderungen an Interrupt-Routinen ==

Um unliebsamen Überraschungen vorzubeugen, sollten einige Grundregeln bei der Implementierung der Interruptroutinen beachtet werden. Interruptroutinen sollten möglichst kurz und schnell abarbeitbar sein, daraus folgt:

* Keine umfangreichen Berechnungen innerhalb der Interruptroutine. (*)
* Keine langen Programmschleifen.
* Obwohl es möglich ist, während der Abarbeitung einer Interruptroutine andere oder sogar den gleichen Interrupt wieder zuzulassen, wird davon ohne genaue Kenntnis der internen Abläufe dringend abgeraten.

Interruptroutinen (ISRs) sollten also möglichst kurz sein und keine Schleifen mit vielen Durchläufen enthalten. Längere Operationen können meist in einen "Interrupt-Teil" in einer ISR und einen "Arbeitsteil" im Hauptprogramm aufgetrennt werden. Z.B. Speichern des Zustands aller Eingänge im EEPROM in bestimmten Zeitabständen: ISR-Teil: Zeitvergleich (Timer,RTC) mit Logzeit/-intervall. Bei Übereinstimmung ein globales Flag setzen (volatile bei Flag-Deklaration nicht vergessen, s.u.). Dann im Hauptprogramm prüfen, ob das Flag gesetzt ist. Wenn ja: die Daten im EEPROM ablegen und Flag löschen.

(*)
Hinweis:
Es gibt allerdings die seltene Situation, dass man gerade eingelesene
ADC-Werte sofort verarbeiten muss. Besonders dann, wenn man mehrere Werte sehr
schnell hintereinander bekommt. Dann bleibt einem nichts anderes übrig, als die
Werte noch in der ISR zu verarbeiten. Kommt aber sehr selten vor und sollte
durch geeignete Wahl des Systemtaktes bzw. Auswahl des Controllers vermieden werden!

== Interrupt-Quellen ==

Die folgenden Ereignisse können einen Interrupt auf einem AVR AT90S2313 auslösen, wobei die Reihenfolge der Auflistung auch die Priorität der Interrupts aufzeigt.

* Reset
* Externer Interrupt 0
* Externer Interrupt 1
* Timer/Counter 1 Capture Ereignis
* Timer/Counter 1 Compare Match
* Timer/Counter 1 Überlauf
* Timer/Counter 0 Überlauf
* UART Zeichen empfangen
* UART Datenregister leer
* UART Zeichen gesendet
* Analoger Komparator

Die Anzahl der möglichen Interruptquellen variiert zwischen den verschiedenen Microcontroller-Typen. Im Zweifel hilft ein Blick ins Datenblatt ("Interrupt Vectors").

== Register ==

Der AT90S2313 verfügt über 2 Register die mit den
Interrupts zusammenhängen.

{| class="wikitable"
|-
| '''GIMSK'''
| '''G'''eneral '''I'''nterrupt '''M'''a'''sk''' Register. 

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6|| 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INT1''' || '''INT0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INT1''' (External '''Int'''errupt Request '''1''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT1'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

'''INT0''' (External '''Int'''errupt Request '''0''' Enable)
:Wenn dieses Bit gesetzt ist, wird ein Interrupt ausgelöst, wenn am '''INT0'''-Pin eine steigende oder fallende (je nach Konfiguration im '''MCUCR''') Flanke erkannt wird.
:Das Global Enable Interrupt Flag muss selbstverständlich auch gesetzt sein.
:Der Interrupt wird auch ausgelöst, wenn der Pin als Ausgang geschaltet ist. Auf diese Weise bietet sich die Möglichkeit, Software-Interrupts zu realisieren.

|-
| '''GIFR'''
| '''G'''eneral '''I'''nterrupt '''F'''lag '''R'''egister.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''INTF1''' || '''INTF0''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-''' || '''-'''
|-
! R/W
| R/W || R/W || R || R || R || R || R || R
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''INTF1''' (External '''Int'''errupt Flag '''1''')
:Dieses Bit wird gesetzt, wenn am '''INT1'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.

'''INTF0''' (External '''Int'''errupt Flag '''0''')
:Dieses Bit wird gesetzt, wenn am '''INT0'''-Pin eine Interrupt-Bedingung, entsprechend der Konfiguration, als eingetreten erkannt wird. Wenn das Global Enable Interrupt Flag gesetzt ist, wird die Interruptroutine angesprungen.
:Das Flag wird automatisch gelöscht, wenn die Interruptroutine beendet ist. Alternativ kann das Flag gelöscht werden, indem der Wert '''1(!)''' eingeschrieben wird.
|-
| '''MCUCR'''
| '''MCU''' '''C'''ontrol '''R'''egister.

Das MCU Control Register enthält Kontrollbits für allgemeine MCU-Funktionen.

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| '''-'''|| '''-'''|| '''SE'''|| '''SM'''|| '''ISC11'''|| '''ISC10'''|| '''ISC01'''|| '''ISC00'''
|-
! R/W
| R || R || R/W || R/W || R/W || R/W || R/W || R/W
|-
! Initialwert
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0

|}

'''SE''' ('''S'''leep '''E'''nable)
:Dieses Bit muss gesetzt sein, um den Controller mit dem '''SLEEP'''-Befehl in den Schlafzustand versetzen zu können.
:Um den Schlafmodus nicht irrtümlich einzuschalten, wird empfohlen, das Bit erst unmittelbar vor Ausführung des '''SLEEP'''-Befehls zu setzen.

'''SM''' ('''S'''leep '''M'''ode)
:Dieses Bit bestimmt über den Schlafmodus.
:Ist das Bit gelöscht, so wird der '''Idle'''-Modus ausgeführt. Ist das Bit gesetzt, so wird der '''Power-Down'''-Modus ausgeführt. (für andere AVR Controller siehe Abschnitt "Sleep-Mode")

'''ISC11''', '''ISC10''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''1''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT1'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC11 || ISC10 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT1''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT1''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT1''' erzeugt einen Interrupt.
|}

'''ISC01''', '''ISC00''' ('''I'''nterrupt '''S'''ense '''C'''ontrol '''0''' Bits)
:Diese beiden Bits bestimmen, ob die steigende oder die fallende Flanke für die Interrupterkennung am '''INT0'''-Pin ausgewertet wird.

:{| class="wikitable"
|-
! ISC01 || ISC00 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Low Level an '''INT0''' erzeugt einen Interrupt.

Der Interrupt wird getriggert, solange der Pin auf 0 bleibt.
|-
| align="center" | 0
| align="center" | 1
| Reserviert
|-
| align="center" | 1
| align="center" | 0
| Die fallende Flanke an '''INT0''' erzeugt einen Interrupt.
|-
| align="center" | 1
| align="center" | 1
| Die steigende Flanke an '''INT0''' erzeugt einen Interrupt.
|}

|}

== Allgemeines über die Interrupt-Abarbeitung ==

Wenn ein Interrupt eintrifft, wird automatisch das '''Global Interrupt Enable''' Bit im Status Register '''SREG''' gelöscht und alle weiteren Interrupts unterbunden. Dieses wird automatisch wieder gesetzt, wenn die Interruptroutine beendet wird. Wenn in der Zwischenzeit weitere Interrupts eintreffen, werden die zugehörigen Interrupt-Bits gesetzt und die Interrupts bei Beendigung der laufenden Interrupt-Routine in der Reihenfolge ihrer Priorität ausgeführt. Dies kann
eigentlich nur dann zu Problemen führen, wenn ein hoch priorisierter Interrupt ständig und in kurzer Folge auftritt. Dieser sperrt dann möglicherweise alle anderen Interrupts mit niedrigerer Priorität. Dies ist einer der Gründe, weshalb die Interrupt-Routinen sehr kurz gehalten werden sollen. Es ist möglich das GIE-Bit in der ISR zu setzen und so schon wieder weitere Interrupts zuzulassen - allerdings sollte man damit vorsichtig sein und genau wissen was man damit macht. Kritisch wird es vor allem wenn der gleiche Interrupt noch einmal kommt, bevor die ISR abgearbeitet ist.



== Interrupts mit avr-gcc ==



Funktionen zur Interrupt-Verarbeitung werden in den Includedateien ''interrupt.h'' der avr-libc zur Verfügung gestellt (bei älterem Quellcode zusätzlich ''signal.h'').

<syntaxhighlight lang="c">
// fuer sei(), cli() und ISR():
#include <avr/interrupt.h>
</syntaxhighlight>

Das Makro '''sei()''' schaltet die Interrupts ein. Eigentlich wird nichts anderes gemacht, als das '''Global Interrupt Enable''' Bit im Status Register gesetzt.

<syntaxhighlight lang="c">
sei();
</syntaxhighlight>

Das Makro '''cli()''' schaltet die Interrupts aus, oder anders gesagt, das '''Global Interrupt Enable''' Bit im Status Register wird gelöscht.

<syntaxhighlight lang="c">
cli();
</syntaxhighlight>

Oft steht man vor der Aufgabe, dass eine Codesequenz nicht unterbrochen werden darf. Es liegt dann nahe, zu Beginn dieser Sequenz ein cli() und am Ende ein sei() einzufügen. Dies ist jedoch ungünstig, wenn die Interrupts vor Aufruf der Sequenz deaktiviert waren und danach auch weiterhin deaktiviert bleiben sollen. Ein sei() würde ungeachtet des vorherigen Zustands die Interrupts aktivieren, was zu unerwünschten Seiteneffekten führen kann. Die aus dem folgenden Beispiel ersichtliche Vorgehensweise ist in solchen Fällen vorzuziehen:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>

//...

void NichtUnterbrechenBitte(void)
{
uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister

tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern
cli(); // Interrupts global deaktivieren

/* hier "unterbrechnungsfreier" Code */

/* Beispiel Anfang
JTAG-Interface eines ATmega16 per Software deaktivieren
und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229):
Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben
werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde
die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */

MCUCSR |= (1<<JTD);
MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information

/* Beispiel Ende */

SREG = tmp_sreg; // Status-Register wieder herstellen
// somit auch das I-Flag auf gesicherten Zustand setzen
}

void NichtSoGut(void)
{
cli();

/* hier "unterbrechnungsfreier" Code */

sei();
}

int main(void)
{
//...

cli();
// Interrupts global deaktiviert

NichtUnterbrechenBitte();
// auch nach Aufruf der Funktion deaktiviert

sei();
// Interrupts global aktiviert

NichtUnterbrechenBitte();
// weiterhin aktiviert
//...

/* Verdeutlichung der unguenstigen Vorgehensweise mit cli/sei: */
cli();
// Interrupts jetzt global deaktiviert

NichtSoGut();
// nach Aufruf der Funktion sind Interrupts global aktiviert
// dies ist mglw. ungewollt!
//...

}
</syntaxhighlight>


Zu den aktivierten Interrupts ist eine Funktion zu programmieren, deren Code aufgerufen wird, wenn der betreffende Interrupt auftritt (Interrupt-Handler, Interrupt-Service-Routine). Dazu existiert die Definition (ein Makro) '''ISR'''.

=== ISR ===

(''ISR()'' ersetzt bei neueren Versionen der avr-libc ''SIGNAL()''. SIGNAL sollte nicht mehr genutzt werden, zur Portierung von SIGNAL nach ISR siehe den [[AVR-GCC-Tutorial#Anhang|Anhang]].)

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
//...
ISR(Vectorname) /* vormals: SIGNAL(siglabel) dabei Vectorname != siglabel ! */
{
/* Interrupt Code */
}
</syntaxhighlight>

Mit ''ISR'' wird eine Funktion für die Bearbeitung eines Interrupts eingeleitet. Als Argument muss dabei die Benennung des entsprechenden Interruptvektors angegeben werden. Diese sind in den jeweiligen Includedateien IOxxxx.h zu finden. Die Bezeichnung entspricht dem Namen aus dem Datenblatt, bei dem die Leerzeichen durch Unterstriche ersetzt sind und ein ''_vect'' angehängt ist.

Als Beispiel ein Ausschnitt aus der Datei für den ATmega8 (bei WinAVR Standardinstallation in C:\WinAVR\avr\include\avr\iom8.h) in der neben den aktuellen Namen für ''ISR'' (*_vect) noch die Bezeichnungen für das inzwischen nicht mehr aktuelle ''SIGNAL'' (SIG_*) enthalten sind.

<syntaxhighlight lang="c">
//...
/* $Id: iom8.h,v 1.13 2005/10/30 22:11:23 joerg_wunsch Exp $ */

/* avr/iom8.h - definitions for ATmega8 */
//...

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect _VECTOR(1)
#define SIG_INTERRUPT0 _VECTOR(1)

/* External Interrupt Request 1 */
#define INT1_vect _VECTOR(2)
#define SIG_INTERRUPT1 _VECTOR(2)

/* Timer/Counter2 Compare Match */
#define TIMER2_COMP_vect _VECTOR(3)
#define SIG_OUTPUT_COMPARE2 _VECTOR(3)

/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect _VECTOR(4)
#define SIG_OVERFLOW2 _VECTOR(4)

/* Timer/Counter1 Capture Event */
#define TIMER1_CAPT_vect _VECTOR(5)
#define SIG_INPUT_CAPTURE1 _VECTOR(5)

/* Timer/Counter1 Compare Match A */
#define TIMER1_COMPA_vect _VECTOR(6)
#define SIG_OUTPUT_COMPARE1A _VECTOR(6)

/* Timer/Counter1 Compare Match B */
#define TIMER1_COMPB_vect _VECTOR(7)
#define SIG_OUTPUT_COMPARE1B _VECTOR(7)

//...
</syntaxhighlight>


Mögliche Funktionsrümpfe für Interruptfunktionen sind zum Beispiel:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>
/* veraltet: #include <avr/signal.h> */

ISR(INT0_vect) /* veraltet: SIGNAL(SIG_INTERRUPT0) */
{
/* Interrupt Code */
}

ISR(TIMER0_OVF_vect) /* veraltet: SIGNAL(SIG_OVERFLOW0) */
{
/* Interrupt Code */
}

ISR(USART_RXC_vect) /* veraltet: SIGNAL(SIG_UART_RECV) */
{
/* Interrupt Code */
}

// und so weiter und so fort...
</syntaxhighlight>

Auf die korrekte Schreibweise der Vektorbezeichnung ist zu achten. Der gcc-Compiler prüft erst ab Version 4.x, ob ein Signal/Interrupt der angegebenen Bezeichnung tatsächlich in der Includedatei definiert ist und gibt andernfalls eine Warnung aus. Bei WinAVR (ab 2/2005) wurde die Überprüfung auch in den mitgelieferten Compiler der Version 3.x integriert. Aus dem gcc-Quellcode Version 3.x selbst erstellte Compiler enthalten die Prüfung nicht (vgl. [[AVR-GCC]]).

Während der Ausführung der Funktion sind alle weiteren Interrupts automatisch gesperrt. Beim Verlassen der Funktion werden die Interrupts wieder zugelassen.

Sollte während der Abarbeitung der Interruptroutine ein weiterer Interrupt (gleiche oder andere Interruptquelle) auftreten, so wird das entsprechende Bit im zugeordneten Interrupt Flag Register gesetzt und die entsprechende Interruptroutine automatisch nach dem Beenden der aktuellen Funktion aufgerufen.

Ein Problem ergibt sich eigentlich nur dann, wenn während der Abarbeitung der aktuellen Interruptroutine mehrere gleichartige Interrupts auftreten. Die entsprechende Interruptroutine wird im Nachhinein zwar aufgerufen jedoch wissen wir nicht, ob nun der entsprechende Interrupt einmal, zweimal oder gar noch öfter aufgetreten ist. Deshalb soll hier noch einmal betont werden, dass Interruptroutinen so schnell wie nur irgend möglich wieder verlassen werden sollten.

=== Unterbrechbare Interruptroutinen ===

"Faustregel": im Zweifel '''ISR'''. Die nachfolgend beschriebene Methode nur dann verwenden, wenn man sich über die unterschiedliche Funktionsweise im Klaren ist.

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR(XXX,ISR_NOBLOCK) /* veraltet: INTERRUPT(SIG_OVERFLOW0) */
{
/* Interrupt-Code */
}
</syntaxhighlight>

Hierbei steht XXX für den oben beschriebenen Namen des Vektors (also z. B. ''TIMER0_OVF_vect''). Der Unterschied im Vergleich zu einer herkömmlichen ISR ist, dass hier beim Aufrufen der Funktion das '''Global Enable Interrupt''' Bit durch Einfügen einer SEI-Anweisung direkt wieder gesetzt und somit alle Interrupts zugelassen werden – auch XXX-Interrupts.

Bei unsachgemässer Handhabung kann dies zu erheblichen Problemen durch Rekursion wie einem Stack-Overflow oder anderen unerwarteten Effekten führen und sollte wirklich nur dann eingesetzt werden, wenn man sich sicher ist, das Ganze auch im Griff zu haben.

Insbesondere sollte möglichst am ISR-Anfang die auslösende IRQ-Quelle deaktiviert und erst am Ende der ISR wieder aktiviert werden. Robuster als die Verwendung einer NOBLOCK-ISR ist daher folgender ISR-Aufbau:

<syntaxhighlight lang="c">
#include <avr/interrupt.h>

ISR (XXX)
{
// Implementiere die ISR ohne zunaechst weitere IRQs zuzulassen

<<Deaktiviere die XXX-IRQ>>

// Erlaube alle Interrupts (ausser XXX)
sei();

//... Code ...

// IRQs global deaktivieren um die XXX-IRQ wieder gefahrlos
// aktivieren zu koennen
cli();

<<Aktiviere die XXX-IRQ>>
}
</syntaxhighlight>
Auf diese Weise kann sich die XXX-IRQ nicht selbst unterbrechen, was zu einer Art Endlosschleife führen würde.

Siehe auch: Hinweise in [[AVR-GCC]]

siehe dazu: http://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html

== Datenaustausch mit Interrupt-Routinen ==

Variablen, die sowohl in Interrupt-Routinen (ISR = Interrupt Service Routine(s)) als auch vom übrigen Programmcode geschrieben oder gelesen werden, müssen mit einem '''volatile''' deklariert werden. Damit wird dem Compiler mitgeteilt, dass der Inhalt der Variablen vor jedem Lesezugriff aus dem Speicher gelesen und nach jedem Schreibzugriff in den Speicher geschrieben wird. Ansonsten könnte der Compiler den Code so optimieren, dass der Wert der Variablen nur in Prozessorregistern zwischengespeichert wird, die nichts von der Änderung woanders mitbekommen.

Zur Veranschaulichung ein Codefragment für eine Tastenentprellung mit Erkennung einer "lange gedrückten" Taste.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdint.h>
//...

// Schwellwerte
// Entprellung:
#define CNTDEBOUNCE 10
// "lange gedrueckt:"
#define CNTREPEAT 200

// hier z. B. Taste an Pin2 PortA "active low" = 0 wenn gedrueckt
#define KEY_PIN PINA
#define KEY_PINNO PA2

// beachte: volatile!
volatile uint8_t gKeyCounter;

// Timer-Compare Interrupt ISR, wird z.B. alle 10ms ausgefuehrt
ISR(TIMER1_COMPA_vect)
{
// hier wird gKeyCounter veraendert. Die übrigen
// Programmteile müssen diese Aenderung "sehen":
// volatile -> aktuellen Wert immer in den Speicher schreiben
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
}
else {
gKeyCounter = 0;
}
}

//...

int main(void)
{
//...
/* hier: Initialisierung der Ports und des Timer-Interrupts */
//...
// hier wird auf gKeyCounter zugegriffen. Dazu muss der in der
// ISR geschriebene Wert bekannt sein:
// volatile -> aktuellen Wert immer aus dem Speicher lesen
if ( gKeyCounter > CNTDEBOUNCE ) { // Taste mind. 10*10 ms "prellfrei"
if (gKeyCounter == CNTREPEAT) {
/* hier: Code fuer "Taste lange gedrueckt" */
}
else {
/* hier: Code fuer "Taste kurz gedrueckt" */
}
}
//...
}
</syntaxhighlight>

Wird innerhalb einer ISR mehrfach auf eine mit volatile deklarierte Variable zugegriffen, wirkt sich dies ungünstig auf die Verarbeitungsgeschwindigkeit aus, da bei jedem Zugriff mit dem Speicherinhalt abgeglichen wird. Da bei AVR-Controllern ''innerhalb'' einer ISR keine Unterbrechungen zu erwarten sind, bietet es sich an, einen Zwischenspeicher in Form einer lokalen Variable zu verwenden, deren Inhalt zu Beginn und am Ende mit dem der volatile Variable synchronisiert wird. Lokale Variable werden bei eingeschalteter Optimierung mit hoher Wahrscheinlichkeit in Prozessorregistern verwaltet und der Zugriff darauf ist daher nur mit wenigen internen Operationen verbunden. Die ISR aus dem vorherigen Beispiel lässt sich so optimieren:

<syntaxhighlight lang="c">
//...
ISR(TIMER1_COMPA_vect)
{
uint8_t tmp_kc;

tmp_kc = gKeyCounter; // Uebernahme in lokale Arbeitsvariable

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
if (tmp_kc < CNTREPEAT) {
tmp_kc++;
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc; // Zurueckschreiben
}
//...
</syntaxhighlight>

Zum Vergleich die Disassemblies (Ausschnitte der "lss-Dateien", compiliert für ATmega162) im Anschluss. Man erkennt den viermaligen Zugriff auf die Speicheraddresse von ''gKeyCounter'' (hier 0x032A) in der ISR ohne "Cache"-Variable und den zweimaligen Zugriff in der Variante mit Zwischenspeicher. Im Beispiel ist der Vorteil gering, bei komplexeren Routinen kann die Zwischenspeicherung in lokalen Variablen jedoch zu deutlicheren Verbesserungen führen.

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
876: ca 99 sbic 0x19, 2 ; 25
878: 0a c0 rjmp .+20 ; 0x88e <__vector_13+0x24>
if (gKeyCounter < CNTREPEAT) gKeyCounter++;
87a: 80 91 2a 03 lds r24, 0x032A
87e: 88 3c cpi r24, 0xC8 ; 200
880: 40 f4 brcc .+16 ; 0x892 <__vector_13+0x28>
882: 80 91 2a 03 lds r24, 0x032A
886: 8f 5f subi r24, 0xFF ; 255
888: 80 93 2a 03 sts 0x032A, r24
88c: 02 c0 rjmp .+4 ; 0x892 <__vector_13+0x28>
}
else {
gKeyCounter = 0;
88e: 10 92 2a 03 sts 0x032A, r1
892: 8f 91 pop r24
894: 0f 90 pop r0
896: 0f be out 0x3f, r0 ; 63
898: 0f 90 pop r0
89a: 1f 90 pop r1
89c: 18 95 reti
</pre>

<pre>
ISR(TIMER1_COMPA_vect)
{
86a: 1f 92 push r1
86c: 0f 92 push r0
86e: 0f b6 in r0, 0x3f ; 63
870: 0f 92 push r0
872: 11 24 eor r1, r1
874: 8f 93 push r24
uint8_t tmp_kc;

tmp_kc = gKeyCounter;
876: 80 91 2a 03 lds r24, 0x032A

if ( !(KEY_PIN & (1<<KEY_PINNO)) ) {
87a: ca 9b sbis 0x19, 2 ; 25
87c: 02 c0 rjmp .+4 ; 0x882 <__vector_13+0x18>
87e: 80 e0 ldi r24, 0x00 ; 0
880: 03 c0 rjmp .+6 ; 0x888 <__vector_13+0x1e>
if (tmp_kc < CNTREPEAT) {
882: 88 3c cpi r24, 0xC8 ; 200
884: 08 f4 brcc .+2 ; 0x888 <__vector_13+0x1e>
tmp_kc++;
886: 8f 5f subi r24, 0xFF ; 255
}
}
else {
tmp_kc = 0;
}

gKeyCounter = tmp_kc;
888: 80 93 2a 03 sts 0x032A, r24
88c: 8f 91 pop r24
88e: 0f 90 pop r0
890: 0f be out 0x3f, r0 ; 63
892: 0f 90 pop r0
894: 1f 90 pop r1
896: 18 95 reti
</pre>

=== volatile und Pointer ===

Bei '''volatile''' in Verbindung mit Pointern ist zu beachten, ob der Pointer selbst oder die Variable, auf die der Pointer zeigt, '''volatile''' ist.

<syntaxhighlight lang="c">
volatile uint8_t *a; // das Ziel von a ist volatile

uint8_t *volatile a; // a selbst ist volatile
</syntaxhighlight>

Falls der Pointer volatile ist (zweiter Fall im Beispiel), ist zu beachten, dass der Wert des Pointers, also eine Speicheradresse, intern in mehr als einem Byte verwaltet wird. Lese- und Schreibzugriffe im Hauptprogramm (außerhalb von Interrupt-Routinen) sind daher so zu implementieren, dass alle Teilbytes der Adresse konsistent bleiben, vgl. dazu den folgenden Abschnitt.

=== Variablen größer 1 Byte ===

Bei Variablen größer ein Byte, auf die in Interrupt-Routinen und im Hauptprogramm zugegriffen wird, muss darauf geachtet werden, dass die Zugriffe auf die einzelnen Bytes außerhalb der ISR nicht durch einen Interrupt unterbrochen werden. (Allgemeinplatz: AVRs sind 8-bit Controller). Zur Veranschaulichung ein Codefragment:

<syntaxhighlight lang="c">
//...
volatile uint16_t gMyCounter16bit;
//...
ISR(...)
{
//...
gMyCounter16Bit++;
//...
}

int main(void)
{
uint16_t tmpCnt;
//...
// nicht gut: Mglw. hier ein Fehler, wenn ein Byte von MyCounter
// schon in tmpCnt kopiert ist aber vor dem Kopieren des zweiten Bytes
// ein Interrupt auftritt, der den Inhalt von MyCounter verändert.
tmpCnt = gMyCounter16bit;

// besser: Änderungen "außerhalb" verhindern -> alle "Teilbytes"
// bleiben konsistent
cli(); // Interrupts deaktivieren
tmpCnt = gMyCounter16Bit;
sei(); // wieder aktivieren

// oder: vorheriger Status des globalen Interrupt-Flags bleibt erhalten
uint8_t sreg_tmp;
sreg_tmp = SREG; /* Sichern */
cli()
tmpCnt = gMyCounter16Bit;
SREG = sreg_tmp; /* Wiederherstellen */

// oder: mehrfach lesen, bis man konsistente Daten hat
uint16_t count1 = gMyCounter16Bit;
uint16_t count2 = gMyCounter16Bit;
while (count1 != count2) {
count1 = count2;
count2 = gMyCounter16Bit;
}
tmpCnt = count1;
//...
}
</syntaxhighlight>

Die avr-libc bietet ab Version 1.6.0(?) einige Hilfsfunktionen/Makros, mit der im Beispiel oben gezeigten Funktionalität, die zusätzlich auch sogenannte [http://en.wikipedia.org/wiki/Memory_barrier memory barriers] beinhalten. Diese stehen nach #include <util/atomic.h> zur Verfügung.
<syntaxhighlight lang="c">
//...
#include <util/atomic.h>
//...

// analog zu cli, Zugriff, sei:
ATOMIC_BLOCK(ATOMIC_FORCEON) {
tmpCnt = gMyCounter16Bit;
}

// oder:

// analog zu Sicherung des SREG, cli, Zugriff und Zurückschreiben des SREG:
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
tmpCnt = gMyCounter16Bit;
}

//...
</syntaxhighlight>

* siehe auch [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Dokumentation der avr-libc zu atomic.h]

== Interrupt-Routinen und Registerzugriffe ==

Falls Register sowohl im Hauptprogramm als auch in Interrupt-Routinen verändert werden, ist darauf zu achten, dass diese Zugriffe sich nicht überlappen. Nur wenige Anweisungen lassen sich in sogenannte "atomare" Zugriffe übersetzen, die nicht von Interrupt-Routinen unterbrochen werden können.

Zur Veranschaulichung eine Anweisung, bei der ein Bit und im Anschluss drei Bits in einem Register gesetzt werden:

<syntaxhighlight lang="c">
#include <avr/io.h>

int main(void)
{
//...
PORTA |= (1<<PA0);

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
//...
}
</syntaxhighlight>

Der Compiler übersetzt diese Anweisungen für einen ATmega128 bei Optimierungsstufe "S" nach:

<div class="code"><pre>
...
PORTA |= (1<<PA0);
d2: d8 9a sbi 0x1b, 0 ; 27 (a)

PORTA |= (1<<PA2)|(1<<PA3)|(1<<PA4);
d4: 8b b3 in r24, 0x1b ; 27 (b)
d6: 8c 61 ori r24, 0x1C ; 28 (c)
d8: 8b bb out 0x1b, r24 ; 27 (d)
...
</pre></div>

Das Setzen des einzelnen Bits wird bei eingeschalteter Optimierung für Register im unteren Speicherbereich in eine einzige Assembler-Anweisung (sbi) übersetzt und ist nicht anfällig für Unterbrechungen durch Interrupts. Die Anweisung zum Setzen von drei Bits wird jedoch in drei abhängige Assembler-Anweisungen übersetzt und bietet damit zwei "Angriffspunkte" für Unterbrechungen. Eine Interrupt-Routine könnte nach dem Laden des Ausgangszustands in den Zwischenspeicher (hier Register 24) den Wert des Registers ändern, z. B. ein Bit löschen. Damit würde der Zwischenspeicher nicht mehr mit dem tatsächlichen Zustand übereinstimmen aber dennoch nach der Bitoperation (hier ori) in das Register zurückgeschrieben.

Beispiel: PORTA sei anfangs 0b00000000. Die erste Anweisung (a) setzt Bit 0 auf '''1''', PORTA ist danach 0b0000000'''1'''. Nun wird im ersten Teil der zweiten Anweisung der Portzustand in ein Register eingelesen (b). Unmittelbar darauf (vor (c)) "feuert" ein Interrupt, in dessen Interrupt-Routine Bit 0 von PORTA gelöscht wird. Nach Verlassen der Interrupt-Routine hat PORTA den Wert 0b00000000. In den beiden noch folgenden Anweisungen des Hauptprogramms wird nun der zwischengespeicherte "alte" Zustand 0b00000001 mit 0b00011100 logisch-'''ODER'''-verknüft (c) und das Ergebnis 0b00011101 in PortA geschrieben (d). Obwohl zwischenzeitlich Bit 0 gelöscht wurde, ist es nach (d) wieder gesetzt.

Lösungsmöglichkeiten:
* Register ohne besondere Vorkehrungen nicht in Interruptroutinen ''und'' im Hauptprogramm verändern.
* Interrupts vor Veränderungen in Registern, die auch in ISRs verändert werden, deaktivieren ("cli").
* Bits einzeln löschen oder setzen. sbi und cbi können nicht unterbrochen werden. Vorsicht: nur Register im unteren Speicherbereich sind mittels sbi/cbi ansprechbar. Der Compiler kann nur für diese sbi/cbi-Anweisungen generieren. Für Register außerhalb dieses Adressbereichs ("Memory-Mapped"-Register) werden auch zur Manipulation einzelner Bits abhängige Anweisungen erzeugt (lds,...,sts).

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Frequently asked Questions/Fragen Nr. 1 und 8. (Stand: avr-libc Vers. 1.0.4)

== Interruptflags löschen ==

Beim Löschen von Interruptflags haben AVRs eine Besonderheit, die auch im Datenblatt beschrieben ist: Es wird zum Löschen eine 1 in das betreffende Bit geschrieben.

Hinweis: 
Bei Registern mit mehreren Interrupt-Flag-Bits (wie die Timer Interrupt Flag Register) '''nicht''' die übliche bitweise VerODERung nehmen, sondern eine direkte Zuweisung machen. Da sonst weitere Flags, als nur das gewünschte, ebenfalls gelöscht werden könnten. 
([http://www.mikrocontroller.net/topic/171148#1640133 Erklärung]).

== Was macht das Hauptprogramm? ==

Im einfachsten (Ausnahme-)Fall gar nichts mehr. Es ist also durchaus denkbar, ein Programm zu schreiben, welches in der main-Funktion lediglich noch die Interrupts aktiviert und dann in einer Endlosschleife verharrt. Sämtliche Funktionen werden dann in den ISRs abgearbeitet. Diese Vorgehensweise ist jedoch bei den meisten Anwendungen schlecht: man verschenkt eine Verarbeitungsebene und hat außerdem möglicherweise Probleme durch Interruptroutinen, die zu viel Verarbeitungszeit benötigen.

Normalerweise wird man in den Interruptroutinen nur die bei Auftreten des jeweiligen Interruptereignisses unbedingt notwendigen Operationen ausführen lassen. Alle weniger kritischen Aufgaben werden dann im Hauptprogramm abgearbeitet.

* siehe auch: [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Interrupts and Signals

= Sleep-Modes =

AVR Controller verfügen über eine Reihe von sogenannten [[Sleep Mode |''Sleep-Modes'']] ("Schlaf-Modi"). Diese ermöglichen es, Teile des Controllers abzuschalten. Zum Einen kann damit besonders bei Batteriebetrieb Strom gespart werden, zum Anderen können Komponenten des Controllers deaktiviert werden, die die Genauigkeit des Analog-Digital-Wandlers bzw. des Analog-Comparators negativ beeinflussen. Der Controller wird durch Interrupts aus dem Schlaf geweckt. Welche Interrupts den jeweiligen Schlafmodus beenden, ist einer Tabelle im Datenblatt des jeweiligen Controllers zu entnehmen.
Die Funktionen (eigentlich Makros) der avr-libc stehen nach Einbinden der header-Datei ''sleep.h'' zur Verfügung.

;set_sleep_mode (uint8_t mode): Setzt den Schlafmodus, der bei Aufruf von sleep() aktiviert wird. In sleep.h sind einige Konstanten definiert (z. B. SLEEP_MODE_PWR_DOWN). Die definierten Modi werden jedoch nicht alle von sämtlichten AVR-Controllern unterstützt.
;sleep_enable(): Aktiviert den gesetzten Schlafmodus, versetzt den Controller aber noch nicht in den Schlafmodus
;sleep_cpu(): Versetzt den Controller in den Schlafmodus .sleep_cpu wird im Prinzip durch die Assembler-Anweisung ''sleep'' ersetzt.
;sleep_disable(): Deaktiviert den gesetzten Schlafmodus
;sleep_mode(): Versetzt den Controller in den mit set_sleep_mode gewählten Schlafmodus. Das Makro entspricht sleep_enable()+sleep_cpu()+sleep_disable(), beinhaltet also nicht die Aktivierung von Interrupts (besser nicht benutzen).

Bei Anwendung von sleep_cpu() müssen Interrupts also bereits freigeben sein (sei()), da der Controller sonst nicht mehr "aufwachen" kann. sleep_mode() ist nicht geeignet für die Verwendung in ISR Interrupt-Service-Routinen, da bei deren Abarbeitung Interrupts global deaktiviert sind und somit auch die möglichen "Aufwachinterrupts". Abhilfe: stattdessen sleep_enable(), sei(), sleep_cpu(), sleep_disable() und evtl. cli() verwenden (vgl. Dokumentation der avr-libc).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/sleep.h>

int main(void)
{
...

while (1) {
...
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

// Code hier wird erst nach Auftreten eines entsprechenden
// "Aufwach-Interrupts" verarbeitet
...
}
}
</syntaxhighlight>

In älteren Versionenen der avr-libc wurden nicht alle AVR-Controller durch die sleep-Funktionen richtig angesteuert. Mit avr-libc 1.2.0 wurde die Anzahl der unterstützten Typen jedoch deutlich erweitert. Bei nicht-unterstützten Typen erreicht man die gewünschte Funktionalität durch direkte "[[Bitmanipulation]]" der entsprechenden Register (vgl. Datenblatt) und Aufruf des Sleep-Befehls via Inline-Assembler oder sleep_cpu():

<syntaxhighlight lang="c">
#include <avr/io.h>
...
// Sleep-Mode "Power-Save" beim ATmega169 "manuell" aktivieren
SMCR = (3<<SM0) | (1<<SE);
asm volatile ("sleep"::); // alternativ sleep_cpu() aus sleep.h
...
</syntaxhighlight>

== Sleep Modi ==
Zu beachten ist, dass unterschiedliche Prozessoren aus der AVR Familie unterschiedliche Sleep-Modi unterstützen oder nicht unterstützen. Auskunft über die tatsächlichen Gegebenheiten gibt, wie immer, das zum Prozessor gehörende Datenblatt. Die unterschiedlichen Modi unterscheiden sich dadurch, welche Bereiche des Prozessors abgeschaltet werden. Damit korrespondiert unmittelbar welche Möglichkeiten es gibt, den Prozessor aus den jeweiligen Sleep Modus wieder aufzuwecken.

;Idle Mode (SLEEP_MODE_IDLE): Die CPU kann durch SPI, USART, Analog Comperator, ADC, TWI, Timer, Watchdog und irgendeinen anderen Interrupt wieder aufgeweckt werden.

;ADC Noise Reduction Mode (SLEEP_MODE_ADC): In diesem Modus liegt das Hauptaugenmerk darauf, die CPU soweit stillzulegen, dass der ADC möglichst keine Störungen aus dem inneren der CPU auffangen kann. Aufwachen aus diesem Modus kann ausgelöst werden durch den ADC, externe Interrupts, TWI, Timer und Watchdog.

;Power-Down Mode (SLEEP_MODE_PWR_DOWN): In diesem Modus wird ein externer Oszillator (Quarz, Quarzoszillator) gestoppt. Geweckt werden kann die CPU durch einen externen Level Interrupt, TWI, Watchdog, Brown-Out-Reset

;Power-Save-Mode (SLEEP_MODE_PWR_SAVE): Power-Save ist identisch zu Power-Down mit einer Ausnahme: Ist der Timer 2 auf die Verwendung eines externen Taktes konfiguriert, so läuft dieser Timer auch im Power-Save weiter und kann die CPU mit einem Interrupt aufwecken.

;Standby-Mode (SLEEP_MODE_STANDBY, SLEEP_MODE_EXT_STANDBY): Voraussetzung für den Standby-Modus ist die Verwendung eines Quarzes oder eines Quarzoszillators (also einer externen Taktquelle). Ansonsten ist dieser Modus identisch zum Power-Down Modus. Vorteil dieses Modus ist eine kürzere Aufwachzeit.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitt Modules/Power Management and Sleep-Modes
* [http://www.mikrocontroller.net/topic/96369#832712 Forenbeitrag] zur "Nichtverwendung" von sleep_mode in ISRs.

= Zeiger =
Zeiger (engl. ''Pointer'') sind Variablen, die die Adresse von Daten oder Funktionen enthalten und belegen 16 Bits. Die Größe hängt mit dem adressierbaren Speicherbereich zusammen und der GCC reserviert dann den entsprechenden Platz.
Ggf. ist es also günstiger, Indizes auf Arrays (Listen) zu verwenden, so dass der GCC für die Zeigerarithmetik den erforderlichen RAM nur temporär benötigt.

Siehe auch: [[Zeiger]]

= Speicherzugriffe =

Atmel AVR-Controller verfügen typisch über drei Speicher:

* [[RAM]]: Im RAM (genauer statisches RAM/SRAM) wird vom gcc-Compiler Platz für Variablen reserviert. Auch der Stack befindet sich im RAM. Dieser Speicher ist "flüchtig", d.h. der Inhalt der Variablen geht beim Ausschalten oder einem Zusammenbruch der Spannungsversorgung verloren.

* Programmspeicher: Ausgeführt als FLASH-Speicher, seitenweise wiederbeschreibbar. Darin ist das Anwendungsprogramm abgelegt.

* [[EEPROM]]: Nichtflüchtiger Speicher, d.h. der einmal geschriebene Inhalt bleibt auch ohne Stromversorgung erhalten. Byte-weise schreib/lesbar. Im EEPROM werden typischerweise gerätespezifische Werte wie z. B. Kalibrierungswerte von Sensoren abgelegt.

Einige AVRs besitzen keinen RAM-Speicher, lediglich die Register können als "Arbeitsvariablen"
genutzt werden. Da die Anwendung des avr-gcc auf solch "kleinen" Controllern ohnehin selten sinnvoll ist und auch nur bei einigen RAM-losen Typen nach [http://lightner.net/avr/ATtinyAvrGcc.html "Bastelarbeiten"] möglich ist, werden diese Controller hier nicht weiter berücksichtigt. Auch EEPROM-Speicher ist nicht auf allen Typen verfügbar. Generell sollten die nachfolgenden Erläuterungen auf alle ATmega-Controller und die größeren AT90-Typen übertragbar sein. Für die Typen ATtiny2313, ATtiny26 und viele weitere der "ATtiny-Reihe" gelten die Ausführungen ebenfalls.

Siehe auch:
* [[Binäre Daten zum Programm hinzufügen]]
== RAM ==

Die Verwaltung des RAM-Speichers erfolgt durch den Compiler, im Regelfall ist beim Zugriff auf Variablen im RAM nichts Besonderes zu beachten. Die Erläuterungen in jedem brauchbaren C-Buch gelten auch für den vom avr-gcc-Compiler erzeugten Code.

Um Speicher dynamisch (während der Laufzeit) zu reservieren, kann '''malloc()''' verwendet werden. malloc(size) "alloziert" (~reserviert) einen gewissen Speicherblock mit '''size''' Bytes. Ist kein Platz für den neuen Block, wird NULL (0) zurückgegeben.

Wird der angelegte Block zu klein (groß), kann die Größe mit realloc() verändert werden. Den allozierten Speicherbereich kann man mit free() wieder freigeben. Wenn das Freigeben eines Blocks vergessen wird spricht man von einem "Speicherleck" (memory leak).

malloc() legt Speicherblöcke im '''Heap''' an, belegt man zuviel Platz, dann wächst der Heap zu weit nach oben und überschreibt den Stack, und der Controller kommt in Teufels Küche. Das kann leider nicht nur passieren wenn man insgesamt zu viel Speicher anfordert, sondern auch wenn man Blöcke unterschiedlicher Größe in ungünstiger Reihenfolge alloziert/freigibt (siehe Artikel [[Heap-Fragmentierung]]). Aus diesem Grund sollte man malloc() auf Mikrocontrollern sehr sparsam (am besten gar nicht) verwenden.

Beispiel zur Verwendung von malloc():
<syntaxhighlight lang="c">
#include <stdlib.h>

void foo(void) {
// neuen speicherbereich anlegen,
// platz für 10 uint16
uint16_t* pBuffer = malloc(10 * sizeof(uint16_t));

// darauf zugreifen, als wärs ein gewohnter Buffer
pBuffer[2] = 5;

// Speicher (unbedingt!) wieder freigeben
free(pBuffer);
}
</syntaxhighlight>

Wenn (wie in obigem Beispiel) dynamischer Speicher nur für die Dauer einer Funktion benötigt und am Ende wieder freigegeben wird, bietet es sich an, statt malloc() '''alloca()''' zu verwenden. Der Unterschied zu malloc() ist, dass der Speicher auf dem Stack reserviert wird, und beim Verlassen der Funktion automatisch wieder freigegeben wird. Es kann somit kein Speicherleck und keine Fragmentierung entstehen.

siehe auch:
* http://www.nongnu.org/avr-libc/user-manual/malloc.html

== Flash mit PROGMEM und pgm_read ==

→ [http://nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html avr-libc: Doku zu avr/pgmspace.h]

Ein Zugriff auf Konstanten im Programmspeicher ist mittels avr-gcc erst ab Version 4.7 "transparent" möglich. Um Daten aus dem Flash zu lesen, muss die AVR-Instruktion LPM (''Load from Program Memory'') erzeugt werden, bei Controllern mit mehr als 64kiB Flash auch ELMP.

Dazu gibt es das AVR-spezifische GCC-Attribut <tt>progmem</tt>, mit dem eine Variablendeklaration im ''static storage''<ref>Variablen der Speicherklasse ''static storage'' haben eine unbegrenzte Lebensdauer. Beispiel für solche Variablen sind globale Variablen, aber auch static-Variablen innerhalb einer Funktion gehören dazu. Beispiele für Variablen, die nicht ''static storage'' sind: auto-Variablen ("normale" lokale Variablen), register-Variablen, durch malloc geschaffene Objekte, etc.</ref> markiert werden kann:
<syntaxhighlight lang="c">
const int value __attribute__((progmem)) = 1;
</syntaxhighlight>

Effekt ist, dass die so markierte Variable nicht im RAM sondern im Flash angelegt wird. Wird durch "normalen" C-Code auf solch eine Variable zugegriffen, wird jedoch aus dem RAM gelesen und nicht aus dem Flash!

Zum Lesen aus dem Flash stellt die avr-libc daher zahlreiche Makros zur Verfügung. Zudem wird das Makro <tt>PROGMEM</tt> definiert, das etwas Tipparbeit spart:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

const int value PROGMEM = 1;
</syntaxhighlight>

<tt>progmem</tt> funktioniert im Wesentlichen wie ein Section-Attribut, das die Daten in der Section <tt>.progmem.data</tt> ablegt. Im Gegensatz zum Section-Attribut werden jedoch noch weitere Prüfungen unternommen, ab avr-gcc 4.6 etwa muss die entsprechende Variable <tt>const</tt> sein.

=== Integer und float ===

Zum Lesen von Skalaren stellt die avr-libc folgende Makros zu Verfügung, die jeweils ein Argument erhalten: Die 16-Bit Adresse des zu lesenden Wertes<ref>Damit ist der mögliche Speicherbereich für Flash-Konstanten auf 64kiB begrenzt. Einige pgmspace-Funktionen ermöglichen den Lesezugriff auf den gesamten Flash-Speicher, intern via Assembler-Anweisung ELPM. Die Initialisierungswerte des Speicherinhalts jenseits der 64kiB-Marke müssen dann jedoch auf anderem Weg angelegt werden, d.h. nicht per PROGMEM. Evtl. eigene Section und Linker-Optionen. Alt und nicht ganz korrekt: Die avr-libc pgmspace-Funktionen unterstützen nur die unteren 64kiB Flash bei Controllern mit mehr als 64kiB.</ref>

:{| {{Tabelle}}
|+ Übersicht der <tt>pgm_read</tt> Funktionen aus dem Header <tt>avr/pgmspace.h</tt> der avr-libc
|-
! Gelesener Wert || <tt>pgm_read_xxx</tt> || Anzahl Bytes
|-
| <tt>uint8_t</tt> || <tt>pgm_read_byte</tt> || 1
|-
| <tt>uint16_t</tt> || <tt>pgm_read_word</tt> || 2
|-
| <tt>uint32_t</tt> || <tt>pgm_read_dword</tt> || 4
|-
| <tt>float</tt> || <tt>pgm_read_float</tt><ref>ab avr-libc 1.7.0</ref> || 4
|}

Soll ein Zeiger gelesen werden, so verwendet man <tt>pgm_read_word</tt> und castet das Ergebnis zum gewünschten Zeiger-Typ.

;Beispiele:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Byte */
const uint8_t aByte PROGMEM = 123;

/* int-Array */
const int anArray[] PROGMEM = { 18, 3 ,70 };

void foo (void)
{
/* Zeiger */
static const uint8_t* const aPointer PROGMEM = &aByte;

uint8_t a = pgm_read_byte (&aByte);
int a2 = (int) pgm_read_word (&anArray[2]);
const uint8_t* p = (const uint8_t*) pgm_read_word (&aPointer);
}
</syntaxhighlight>

=== Blöcke ===

In den Flash-Funktionen der avr-libc sind keine der pgm_read_xxxx Nomenklatur folgenden Funktionen, die Speicherblöcke auslesen oder vergleichen. Die enstprechende Funktionen sind Varianten von <tt>memcpy</tt>, <tt>memcmp</tt> und heißt <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, usw. Für weitere Funktionen und deren Prototypen siehe die Dokumentation der avr-libc.

=== Strings ===

Strings sind in C nichts anderes als eine Abfolge von Zeichen und einem <tt>'\0'</tt> als Stringende. Der prinzipielle Weg ist daher identisch zum Lesen von Bytes, wobei auf die [[FAQ#Wie funktioniert String-Verarbeitung in C?|Besonderheiten von Strings]] wie 0-Terminierung geachtet werden muss.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

size_t my_string_length (const char* addr)
{
size_t length = 0;

while (pgm_read_byte (addr++))
{
len++;
}
return length;
}
</syntaxhighlight>

Zur Unterstützung des Programmierers steht das Repertoire der str-Funktionen auch in jeweils eine Variante zur Verfügung, die mit dem Flash-Speicher arbeiten kann. Die Funktionsnamen tragen den Suffix <tt>_P</tt>. Darüber hinaus gibt es das Makro <tt>PSTR</tt>, das ein String-Literal im Flash-Speicher ablegt und die Adresse des Strings liefert:

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

/* Liefert true zurück, wenn string_im_ram gleich "Hallo Welt" ist. */
int foo (const char* string_im_ram)
{
return strcmp_P (string_im_ram, PSTR ("Hallo Welt"));
}
</syntaxhighlight>

Zu beachten ist, dass <tt>PSTR</tt> nur innerhalb von Funktionen verwendet werden kann.

; Array aus Strings:

Arrays aus Strings im Flash-Speicher werden in zwei Schritten angelegt:

# Zuerst die einzelnen Elemente des Arrays und
# im Anschluss ein Array, in dem die Startaddressen der Strings abgelegt werden.

Zum Auslesen wird zuerst die Adresse des gewünschten Elements aus dem Array im Flash-Speicher gelesen, die im Anschluss dazu genutzt wird, um auf das Element (den String) selbst zuzugreifen.

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char str1[] PROGMEM = "Hund";
static const char str2[] PROGMEM = "Katze";
static const char str3[] PROGMEM = "Maus";

const char * const array[] PROGMEM =
{
str1, str2, str3
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Lese die Adresse des i-ten Strings aus array[]
const char *parray = (const char*) pgm_read_word (&array[i]);

// Kopiere den Inhalt der Zeichenkette vom Flash ins RAM
strcpy_P (buf, parray);
}
</syntaxhighlight>

Eine weitere Möglichkeit ist, die Strings in einem 2-dimensionalen char-Array abzulegen anstatt deren Adresse in einem 1-dimensionalen Adress-Array zu speichern.

Vorteil ist, dass der Code einfacher wird. Nachteil ist, dass bei unterschiedlich langen Strings Speicherplatz verschwendet wird, weil sich die Array-Dimension and der Länge des längsten Strings orientieret. Bei in etwa gleich langen Strings kann es aber sogar Speicherplatz sparen, denn es die Adressen der einzelnen Strings müssen nicht abgespeichert werden.<ref>In unserem Hund-Katze-Maus Beispiel belegt die erste Variante 22 Bytes Daten und 18 Bytes Code, die zweite Variante mit 2-dimensionalem Array belegt 18 Bytes Daten und 20 Bytes Code. Gemessen wurde mit avr-gcc 4.8 -Os für ATmega8.</ref>

<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Die "6" ist 1 plus die Länge des längsten Strings ("Katze")
const char array[][6] PROGMEM =
{
"Hund", "Katze", "Maus"
};

// Liest den i-ten String von array[] und kopiert ihn ins RAM nach buf[]
void read_string (char* buf, size_t i)
{
// Kopiere den Inhalt der i-ten Zeichenkette vom Flash ins RAM
strcpy_P (buf, array[i]);
}
</syntaxhighlight>

Siehe dazu auch die avr-libc FAQ: [http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_rom_array How do I put an array of strings completely in ROM?]

=== Warum so kompliziert? ===

Zu dem Thema, warum die Verabeitung von Werten aus dem Flash-Speicher so kompliziert ist, sei hier nur kurz erläutert: Die Harvard-Architektur des AVR weist getrennte Adressräume für Programm (Flash) und Datenspeicher (RAM) auf. Der C-Standard sieht keine unterschiedlichen Adressräume vor.

Hat man zum Beispiel eine Funktion string_an_uart (const char* s) und übergibt an diese Funktion die Adresse einer Zeichenkette, dann weiß die Funktion nicht, ob die Adresse in den Flash-Speicher oder das RAM zeigt. Weder aus dem Pointer-Wert, also dem Zahlenwert, noch aus dem "const" kann auf den Ort der Ablage geschlossen werden.

Einige AVR-Compiler bilden die Harvard-Architektur ab, indem sie in einen Pointer nicht nur die Adresse speichern, sondern auch den Ablageort wie ''Flash'' oder ''RAM''. In einem Aufruf einer Funktion wird dann bei Pointer-Parametern neben der Adresse auch der Speicherbereich, auf den der Pointer zeigt, übergeben.

Dies hat jedoch auch Nachteile, denn bei jedem Zugriff über einen Zeiger muss zur ''Laufzeit'' entschieden werden, wie der Zugriff auszuführen ist und entsprechend länglicher und langsamer wird der erzeugte Code.

Siehe auch:
* [http://www.nongnu.org/avr-libc/user-manual/index.html Dokumentation der avr-libc] Abschnitte Modules/Program Space String Utilities und Abschnitt Modules/Bootloader Support Utilities

=== Variablenzugriff >64kB ===

Die Zeiger beim avr-gcc sind nur 16 Bit breit, können somit also nur 64kiB Datenspeicher adressieren. Als Funktionspointer können sie beim AVR bis zu 128 kiB Programmspeicher adressieren, weil Funktionsadressen immer 16-Bit Worte adressieren und nicht Bytes. Um Flashzugriff jenseits von 64KiB zu bewerkstelligen gibt es mehrere Möglichkeiten:

* Address-Spaces wie <tt>__flash1</tt> oder <tt>__memx</tt>, siehe Abschnitt "[[#Jenseits von flash|Jenseits von __flash]]".
* Die Funktionen bzw. Makros <tt>pgm_read_xxx_far</tt> der AVR-Libc, wie im folgenden beschrieben.

Unverständlicherweise gibt es in der AVR-Libc keine Funktion, um 32-Bit Pointer zu erhalten. Hier schafft ein eigenes GNU-C99 Makro Abhilfe:

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <avr/pgmspace.h>

//====================================================================
// Macro to access strings defined in PROGMEM above 64kB
//--------------------------------------------------------------------
#define FAR(var) \
({ uint_farptr_t tmp; \
__asm__ ( \
"ldi %A0, lo8(%1)" "\n\t" \
"ldi %B0, hi8(%1)" "\n\t" \
"ldi %C0, hh8(%1)" \
: "=d" (tmp) \
: "i" (&(var))); \
tmp; \
})
//-------------------------------------------------------------------

//===================================================================
// Define a section above 64kiB (FAR_SECTION)
// and add the required linker argument below
// -Wl,--section-start=.far_section=0x10000
//--------------------------------------------------------------------
#define FAR_SECTION __attribute__((__section__(".far_section")))
//--------------------------------------------------------------------

//====================================================================
// Just a Sample
//--------------------------------------------------------------------

const char MyString[] FAR_SECTION = "Hier liegt mein FAR-Teststring!";
const char MyBmp64[] FAR_SECTION = {0xAA,0xBB,0xCC,0xDD,0xEE,0xFF,0x00};

int main(void)
{
char MyChar;
DDRC = 0xFF;
do
{
MyChar = pgm_read_byte_far(FAR(MyBmp64));
PORTC = MyChar;
}
while(MyChar);
}
</syntaxhighlight>

D.h. man muss
* Das Makro <tt>FAR</tt> im Quellcode einfügen
* Die Definition der neuen Section <tt>FAR_SECTION</tt> einfügen
* Die Variablen mit dieser Section kennzeichnen
* Dem Linker mittels Kommandozeilenoption die Startadrese dieser Section mitteilen

Der Zugriff auf diese Variablen kann nur mittels direkter Pointerarithmetik erfolgen, eine Indizierung von Arrays mit variablem Index ist nicht möglich.

<syntaxhighlight lang="c">
int n=3;
MyChar = pgm_read_byte_far(FAR(MyBmp64)+n);
</syntaxhighlight>

== Flash mit __flash und Embedded-C ==

Ab Version 4.7 unterstützt avr-gcc ''Adress-Spaces'' gemäß dem Embedded-C Dokument ISO/IEC TR18037. Der geläufigste Adress-Space ist <tt>__flash</tt>, der im Gegensatz zu <tt>progmem</tt> kein GCC-Attribut ist, sondern ein Qualifier und damit syntaktisch ähnlich verwendet wird wie <tt>const</tt> oder <tt>volatile</tt>.

GCC kennt keine eigene Option zum Aktivieren von Embedded-C, es wird als GNU-C Erweiterung behandelt. Daher müssen C-Module, die Address-Spaces verwenden, mit <tt>-std=gnu99</tt> o.ä. compiliert werden.

<syntaxhighlight lang="c">
static const __flash int value = 10;

int get_value (void)
{
return value;
}
</syntaxhighlight>

# Im Gegensatz zu <tt>progmem</tt> sind keine speziellen Bibliotheksfunktionen oder -makros für den Zugriff mehr notwendig: Der Code zum Lesen der Variable ist "normales" C.
# Die Variable wird im richtigen Speicherbereich (Flash) angelegt.
# <tt>__flash</tt> ist nur zusammen mit read-only Objekten oder Zeigern, d.h. nur zusammen mit <tt>const</tt>, erlaubt.
# Zugriffe wie im obigen Beispiel können (weg)optimiert werden. Das Beispiel entspricht einem "<tt>return 10</tt>". Es besteht keine Notwendigkeit, für <tt>value</tt> überhaupt Flash-Speicher zu reservieren.

Auch Zeiger-Indirektionen sind problemlos möglich. Zu beachten ist, dass <tt>__flash</tt> auf der richtigen Seite des "<tt>*</tt>" in der Zeigerdeklaration bzw. -definition steht:
* '''Rechts vom <tt>*</tt>:''' Der Zeiger selbst liegt im Flash
* '''Links vom <tt>*</tt>:''' Der Zeiger enthält eine Flash-Adresse

<syntaxhighlight lang="c">
// val ist eine Variable im Flash
const __flash int val = 42;

// pval liegt auch im Flash und enthält die Adresse von val
const __flash int* const __flash pval = &val;

char get_val (void)
{
// liest den Wert von val über die in pval abgelegte Adresse
return *pval;
}
</syntaxhighlight>

=== Blöcke ===

Um Speicherbereiche vom Flash in den RAM zu kopieren, gibt es zwei Möglichkeiten: Zum einen können wie bei <tt>progmem</tt> beschreiben die Funktionen der avr-libc wie <tt>memcpy_P</tt>, <tt>memcmp_P</tt>, <tt>movmem_P</tt>, etc. verwendet werden:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// buf wird auf dem Stack angelegt
data_t buf;

// Kopiere Daten vom Flash nach buf ins RAM
memcpy_P (&buf, pdata, sizeof (data_t));

// Sende die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

Zum anderen kann eine Struktur auch über direktes Kopieren ins RAM geladen werden:

<syntaxhighlight lang="c">
#include <stdlib.h>

// Eine Datenstruktur
typedef struct
{
int id;
char buf[10];
} data_t;

extern void uart_send (const void*, size_t);

void send_data (const __flash data_t *pdata)
{
// Kopiere Daten ins RAM. buf wird auf dem Stack angelegt
const data_t buf = *pdata;

// Verwendet die Daten in buf
uart_send (&buf, sizeof (data_t));
}
</syntaxhighlight>

=== Strings ===

Natürlich können auch Strings im Flash abgelegt werden und auch mit Funktionen wie <tt>strcpy_P</tt> aus der avr-libc verarbeitet werden. Zudem ist es möglich, Flash-Zeiger mit der Adresse eines String-Literals zu initialisieren:
<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

#define FSTR(X) ((const __flash char[]) { X } )

const __flash char * const __flash array[] =
{
FSTR ("Hund"), FSTR ("Katze"), FSTR ("Maus")
};

size_t get_len (uint8_t tier)
{
return strlen_P (array[tier]);
}
</syntaxhighlight>

Leider sieht der Embedded-C Draft nicht vor, String-Literale direkt in einem anderen Adress-Space als ''generic'' anzulegen, so dass hier der Umweg über <tt>FSTR</tt> genommen werden muss. Dieses Konstrukt ist nur ausserhalb von Funktionen möglich und kann daher nicht als Ersatz für <tt>PSTR</tt> aus der avr-libc dienen.

Soll <tt>array</tt> ein 2-dimensonales Array sein anstatt ein 1-dimensionales Array von Zeigern, dann geht das ohne große Verrenkungen:

<syntaxhighlight lang="c">
// Die 6 ergibt sich aus 1 plus der Länge des längsten Strings "Katze"
const __flash char array[][6] =
{
"Hund", "Katze", "Maus"
};
</syntaxhighlight>

Weiters besteht die Möglichkeit, <tt>array</tt> analog anzulegen, wie man es mit <tt>PROGMEM</tt> machen würde: Jeder String wird explizit angelegt und seine Adresse bei der Initialisierung von <tt>array</tt> verwendet. Dies entspricht dem ersten Beispiel eines 1-dimensionalen Zeigerarrays:

<syntaxhighlight lang="c">
static const __flash char strHund[] = "Hund";
static const __flash char strKatze[] = "Katze";
static const __flash char strMaus[] = "Maus";

const __flash char * const __flash array[] =
{
strHund, strKatze, strMaus
};
</syntaxhighlight>

=== Casts ===

Embedded C fordert, dass zwei Adress-Spaces entweder disjunkt sind – d.h. sie enthalten keine gemeinsamen Adressen – oder aber ein Space komplett im anderen enthalten ist, also eine Teilmengen-Beziehung besteht. Die Adress-Spaces von avr-gcc sind so implementiert, dass jeder Space Teilmenge jedes anderes ist. Zwar haben Spaces wie RAM und Flash physikalisch keinen Speicherbereich gemein, allerdings ermöglicht diese Implementierung das Casten von Zeigern zu unterschiedlichen Adress-Spaces<ref>Im Gegensatz zu einem Attribute wie <tt>progmem</tt> ist ein (Adress Space) Qualifier Teil des Zeiger-Typs.</ref>:

<syntaxhighlight lang="c">
#include <stdbool.h>

char read_char (const char *address, bool data_in_flash)
{
if (data_in_flash)
return *(const __flash char*) address;
else
return *address;
}
</syntaxhighlight>

Der Cast selbst erzeugt keinen zusätzlichen Code, da eine RAM-Adresse und eine Flash-Adresse die gleiche Binärdarstellung haben. Allerdings wird über den nach <tt>__flash</tt> gecasteten Zeiger anders zugegriffen, nämlich per LPM.

=== Jenseits von __flash ===

Ausser <tt>__flash</tt> gibt es auch folgende Address-Spaces:

; <tt>__flash</tt>''N'': Mit ''N'' = 1..5 sind fünf weitere Spaces, die analog zu <tt>__flash</tt> funktionieren und deren Zeiger ebenfalls 16 Bit breit sind. avr-gcc erwartet, dass die zugehörigen Daten, welche in die Section <tt>.progmem</tt>''N''<tt>.data</tt> abgelegt werden, so lokatiert sind, dass das high-Byte der Adresse (Bits 16..23) gerade ''N'' ist. Dies wird in Binutils noch nicht unterstützt<ref>[http://sourceware.org/PR14406 Binutils PR14406]: Support .progmem<N>.data sections to work with GCC's [http://gcc.gnu.org/PR49868 PR49868].</ref> (Stand Binutils 2.24) Die Unterstützung kann durch ein eigenes Linker-Skript erreicht werden, welches diese Sections wie vom Compiler erwartet lokatiert.
; <tt>__memx</tt>: Dieser Address-Space implementiert 3-Byte Zeiger und unterstützt Lesen über 64KiB-Segmentgrenzen hinweg. Das MSB (Bit 23) gibt dabei an, ob der <tt>__memx</tt>-Zeiger eine Flash-Adresse enthält (Bit23 = 0) oder eine RAM-Adresse (Bit23 = 1), was folgenden Code erlaubt:

:{|
|-
|<syntaxhighlight lang="c">
const __memx int a_flash = 42;
const int a_ram = 100;

static int get_a (const __memx int* pa)
{
return *pa;
}

int main (void)
{
return get_a (&a_flash) + get_a (&a_ram);
}</syntaxhighlight>
|}Dies bedeutet, dass erst zur ''Laufzeit'' entschieden werden kann, ob aus dem RAM oder aus dem Flash gelesen werden soll, was <tt>__memx</tt> im Vergleich zu den anderen Address-Spaces langsamer macht. Ausserdem ist zu beachten, dass <tt>__memx</tt>-Zeiger zwar 24-Bit Zeiger sind, die zugrundeliegende Adress-Arithmetik jedoch gemäß dem C-Standard erfolgt, also als 16-Bit Arithmetik.

=== __flash, progmem und Portierbarkeit ===

Da ab er aktuellen Compilerversion 4.7 sowohl <tt>__flash</tt> als auch <tt>PROGMEM</tt> und die <tt>pgm_read</tt>-Funktionen zur Verfügung stehen, ergibt sich die Frage, welche Variante "besser" ist und wie zwischen ihnen hin- und her zu portieren ist.

Zunächst sei erwähnt, dass <tt>__flash</tt> kein Ersatz für <tt>PROGMEM</tt> ist, sondern lediglich eine Alternative dazu. Das "alte" progmem wird weiterhin mir gleicher Semantik unterstützt, so dass alter Code ohne Änderungen mit den neueren Compilerversionen übersetzbar bleibt.

Von der Codegüte her dürften sich keine großen Unterschiede ergeben. Es ist nicht zu erwarten, dass die eine oder die andere Variante wesentlich besseren oder schlechteren Code erzeugt — von einer Ausnahme abgesehen: Der Wert beim Zugriff ist zur Compilezeit bekannt und kann daher eliminiert werden.
<syntaxhighlight lang="c">
static const __flash char x[] = { 'A', 'V', 'R' };

char foo (void)
{
return x[2];
}
</syntaxhighlight>
Dies wird übersetzt wie "<tt>return 'R';</tt>", und das Array <tt>x[]</tt> kann komplett wegoptimiert werden und entfallen.

==== progmem → __flash ====

Portierung in diese Richtung bedeutet, alten Code anzupassen. Zwingend ist die Portierung nicht, da <tt>progmem</tt> weiterhin unterstützt wird.
Allerdings ist eine Quelle mit <tt>__flash</tt> besser lesbar, denn der Code wird von den <tt>pgm_read</tt>-Funktionen befreit, die vor allem bei Mehrfach-Indirektion den Code ziemlich verunstalten und unleserlich machen können.
Weiterer Vorteil von <tt>_flash</tt> ist, daß eine striktere Typprüfung erfolgen kann.

Eine Portierung wird man in zwei Schritten vornehmen:

;1. Definitionen von Flash-Variablen werden angepasst:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

static const char hund[] PROGMEM = "Hund";
static const char katze[] PROGMEM = "Katze";
static const char maus[] PROGMEM = "Maus";

const char * const tier[] PROGMEM =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
static const __flash char hund[] = "Hund";
static const __flash char katze[] = "Katze";
static const __flash char maus[] = "Maus";

const __flash char * const __flash tier[] =
{
hund, katze, maus
};
</syntaxhighlight>
|}

Der Header <tt>avr/pgmspace.h</tt> wird nicht mehr benötigt. Im Gegensatz zu <tt>progmem</tt> müssen Qualifier immer links von der definierten Variablen stehen; bei Attributen wie <tt>progmem</tt> ist das mehr oder weniger egal.

Nachdem diese Anpassung erfolgreich abgeschlossen ist, folgt Schritt

; 2. Der Code wird von <tt>pgm_read</tt>-Aufrufen bereinigt:

Vorher:
:{|
|-
|<syntaxhighlight lang="c">
#include <avr/pgmspace.h>

extern const char *tier[];

char first_letter (uint8_t i)
{
const char* ptier = (const char*) pgm_read_word (&tier[i]);
return (char) pgm_read_byte (&ptier[0]);
}
</syntaxhighlight>
|}

Nachher:
:{|
|-
|<syntaxhighlight lang="c">
#include <stdint.h>

extern const __flash char * const __flash tier[];

char first_letter (uint8_t i)
{
return tier[i][0];
}
</syntaxhighlight>
|}

== Dateien direkt im Flash einbinden ==

Wenn man größere Dateien direkt im Programm einbinden will, ohne sie vorher in C Quelltext umzuwandeln, muss man das mit dem Linker machen. Wie das geht steht hier.

* [http://www.atmel.com/webdoc/avrlibcreferencemanual/FAQ_1faq_binarydata.html Atmel, avr gcc Dokumentation]
* [http://nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata Nongnu avr gcc Dokumentation]

Wie man das dann praktisch umsetzt, sieht man in diesem Beitrag.

* [https://www.mikrocontroller.net/topic/361429?goto=4056910#4056910 Forumsbeitrag]: Binärdateien mittels Linker einbinden

== Flash in der Anwendung schreiben ==

Bei AVRs mit "self-programming"-Option – auch bekannt als [[Bootloader]]-Support – können Teile des Flash-Speichers vom Anwendungsprogramm beschrieben werden. Dies ist nur möglich, wenn die Schreibfunktion in einem besonderen Speicherbereich, der Boot-Section des Programmspeichers/Flash, abgelegt ist.

Bei einigen kleinen AVRs gibt es keine gesonderte Boot-Section, bei diesen kann der Flashspeicher von jeder Stelle des Programms geschrieben werden. Für Details sei hier auf das jeweilige Controller-Datenblatt und die Erläuterungen zum Modul boot.h der avr-libc verwiesen. Es existieren auch Application-Notes dazu bei atmel.com, die auf avr-gcc-Code übertragbar sind.

Siehe auch:
* Forumsbeitrag [http://www.mikrocontroller.net/topic/163632#1561622 Daten in Programmspeicher speichern]

== EEPROM ==

Möchte man Werte aus einem Programm heraus so speichern, dass sie auch nach dem Abschalten der Versorgungsspannung noch erhalten bleiben und nach dem Wiederherstellen der Versorgungsspannung bei erneutem Programmstart wieder zur Verfügung stehen, dann benutzt man das EEPROM.

Schreib- und Lesezugriffe auf den EEPROM-Speicher erfolgen über die im Modul eeprom.h der avr-libc definierten Funktionen. Mit diesen Funktionen können einzelne Bytes, Datenworte (16 Bit), Fließkommawerte (32 Bit, single-precision, float) und Datenblöcke geschrieben und gelesen werden.

Diese Funktionen kümmern sich auch um diverse Details, die bei der Benutzung des EEPROMs normalerweise notwendig sind:
* EEPROM-Operationen sind im Vergleich relativ langsam. Man muss daher darauf achten, dass eine vorhergehende Operation abgeschlossen ist, ehe die nächste Operation mit dem EEPROM gestartet wird. Die in der avr-libc implementierten Funktionen aus eeprom.h berücksichtigten dies. Soll beim Aufruf einer EEPROM-Funktion sichergestellt werden, dass diese nicht intern in einer Warteschleife auf den Abschluss der vorherigen Operation wartet, kann vorher per eeprom_is_ready testen, ob der Zugriff auf den EEPROM-Speicher sofort möglich ist.
* Es ist darauf zu achten, dass die EEPROM-Funktionen nicht durch einen Interrupt unterbrochen werden. Einige Phasen des Zugriffs sind zeitkritisch und müssen in einer definierten bzw. begrenzten Anzahl von Takten durchgeführt werden. Durch einen unterbrechenden Interrupt würde diese Restriktion nicht mehr eingehalten. Auch dieses Detail wird von den avr-libc Funktionen berücksichtigt, so dass man sich als C-Programmierer nicht darum kümmern muss. Innerhalb der Funktionen werden Interrupts vor der "EEPROM-Sequenz" global deaktiviert und im Anschluss, falls vorher auch schon eingeschaltet, wieder aktiviert.

Man beachte, dass der EEPROM-Speicher nur eine begrenzte Anzahl von Schreibzugriffen zulässt. Beschreibt man eine EEPROM-Zelle öfter als die im Datenblatt zugesicherte Anzahl (typisch 100.000), wird die Funktion der Zelle nicht mehr garantiert. Dies gilt für jede einzelne Zelle.

Bei geschickter Programmierung (z. B. Ring-Puffer), bei der die zu beschreibenden Zellen regelmäßig gewechselt werden, kann man eine deutlich höhere Anzahl an Schreibzugriffen, bezogen auf den gesamten EEPROM-Speicher, erreichen. Auf jeden Fall sollte man aber eine Abschätzung über die zu erwartende Lebensdauer des EEPROM durchführen. Wird ein Wert im EEPROM im Durchschnitt nur einmal pro Woche verändert, wird die garantierte Anzahl der Schreibzyklen innerhalb der voraussichtlichen Verwendungszeit des Controllers sicherlich nicht erreicht werden. Welcher Controller ist schon 100000 / 52 = 1923 Jahre im Einsatz? In diesem Fall lohnt es sich daher nicht, erweiterte Programmfunktionen zu implementieren, mit denen die Anzahl der Schreibzugriffe minimiert wird.

Eine weitere Möglichkeit, Schreibzyklen einzusparen, besteht in der Vorabprüfung, ob der zu speichernde Wert im EEPROM bereits enthalten ist und nur veränderte Werte zu schreiben. In aktuelleren Versionen der avr-libc sind bereits Funktionen enthalten, die solche Prüfungen enthalten (eeprom_update_*).

Lesezugriffe können beliebig oft durchgeführt werden. Sie unterliegen keinen Einschränkungen in Bezug auf deren Anzahl.

=== EEMEM ===
Um eine Variable im EEPROM anzulegen, stellt die avr-libc das Makro EEMEM zur Verfügung:

<syntaxhighlight lang="c">
#include <stdint.h>
#include <avr/eeprom.h>

/* Byte */
uint8_t eeFooByte EEMEM = 123;

/* Wort */
uint16_t eeFooWord EEMEM = 12345;

/* float */
float eeFooFloat EEMEM;

/* Byte-Array */
uint8_t eeFooByteArray1[] EEMEM = { 18, 3, 70 };
uint8_t eeFooByteArray2[] EEMEM = { 30, 7, 79 };

/* 16-bit unsigned short feld */
uint16_t eeFooWordArray1[4] EEMEM;
</syntaxhighlight>

Die grundsätzliche Vorgehensweise ist identisch zur Verwendung von PROGMEM. Auch hier erzeugt man sich spezielle attributierte Variablen (EEMEM erledigt das), die vom Compiler/Linker nicht wie normale Variablen behandelt werden. Compiler/Linker kümmern sich zwar darum, dass diesen Variablen eine Adresse zugewiesen wird, diese Adresse ist dann aber die Adresse der 'Variablen' im EEPROM. Um die dort gespeicherten Werte zu lesen bzw. zu schreiben, übergibt man diese Adresse an spezielle Funktionen, die die entsprechenden Werte aus dem EEPROM holen bzw. das EEPROM neu beschreiben.

Die mittels EEMEM erzeugten 'Variablen' sind also mehr als Platzhalter zu verstehen, denn als echte Variablen. Es geht nur darum, im C-Programm symbolische Namen zur Verfügung zu haben, anstatt mit echten EEPROM-Adressen hantieren zu müssen, etwas, das grundsätzlich aber auch genauso gut möglich ist. Nur muss man sich in diesem Fall dann selbst darum kümmern, dass mehrere 'Variablen' ohne Überschneidung im EEPROM angeordnet werden.

=== Bytes lesen/schreiben ===

Die avr-libc Funktion zum Lesen eines Bytes heißt eeprom_read_byte. Parameter ist die Adresse des Bytes im EEPROM. Geschrieben wird über die Funktion eeprom_write_byte mit den Parametern Adresse und Inhalt. Anwendungsbeispiel:

<syntaxhighlight lang="c">
#define EEPROM_DEF 0xFF

void eeprom_example (void)
{
uint8_t myByte;

// myByte lesen (Wert = 123)
myByte = eeprom_read_byte (&eeFooByte);

// der Wert 99 wird im EEPROM an die Adresse der
// Variablen eeFooByte geschrieben
myByte = 99;
eeprom_write_byte(&eeFooByte, myByte); // schreiben

myByte = eeprom_read_byte (&eeFooByteArray1[1]);
// myByte hat nun den Wert 3

// Beispiel fuer eeprom_update_byte: die EEPROM-Zelle wird nur
// dann beschrieben, wenn deren Inhalt sich vom Parameterwert
// unterscheidet. In diesem Beispiel erfolgt also kein Schreib-
// zugriff, da die Werte gleich sind.
eeprom_update_byte(&eeFooByte, myByte);

// Beispiel zur "Sicherung" gegen leeres EEPROM nach "Chip Erase"
// (z. B. wenn die .eep-Datei nach Programmierung einer neuen Version
// des Programms nicht in den EEPROM uebertragen wurde und EESAVE
// deaktiviert ist (unprogrammed/1)
//
// Vorsicht: wenn EESAVE "programmed" ist, hilft diese Sicherung nicht
// weiter, da die Speicheraddressen in einem neuen/erweiterten Programm
// moeglicherweise verschoben wurden. An der Stelle &eeFooByte steht
// dann u.U. der Wert einer anderen Variable aus einer "alten" Version.

uint8_t fooByteDefault = 222;
if ((myByte = eeprom_read_byte (&eeFooByte)) == EEPROM_DEF)
{
myByte = fooByteDefault;
}
}
</syntaxhighlight>

=== Wort lesen/schreiben ===

Schreiben und Lesen von Datenworten erfolgt analog zur Vorgehensweise bei Bytes:

<syntaxhighlight lang="c">
// lesen
uint16_t myWord = eeprom_read_word (&eeFooWord);

// schreiben
eeprom_write_word (&eeFooWord, 2222);
</syntaxhighlight>

=== Block lesen/schreiben ===

Lesen und Schreiben von Datenblöcken erfolgt über die Funktionen <code>eeprom_read_block()</code> bzw. <code>eeprom_write_block()</code>. Die Funktionen erwarten drei Parameter: die Adresse der Quell- bzw. Zieldaten im RAM, die EEPROM-Adresse und die Länge des Datenblocks in Bytes als <code>size_t</code>.
<syntaxhighlight lang="c">
uint8_t myByteBuffer[3];
uint16_t myWordBuffer[4];

void eeprom_block_example (void)
{
/* Datenblock aus EEPROM lesen */

/* liest 3 Bytes ab der von eeFooByteArray1 definierten EEPROM-Adresse
in das RAM-Array myByteBuffer */
eeprom_read_block (myByteBuffer, eeFooByteArray1, 3);

/* dito mit etwas Absicherung betr. der Länge */
eeprom_read_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));

/* und nun mit 16-Bit Array */
eeprom_read_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));

/* Datenblock in EEPROM schreiben */
eeprom_write_block (myByteBuffer, eeFooByteArray1, sizeof(myByteBuffer));
eeprom_write_block (myWordBuffer, eeFooWordArray1, sizeof(myWordBuffer));
}
</syntaxhighlight>

=== Fließkommawerte lesen/schreiben ===

In der avr-libc stehen auch EEPROM-Funktionen für Variablen des Typs float (Fließkommazahlen mit "einfacher" Genauigkeit) zur Verfügung.

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

float eeFloat EEMEM = 12.34f;

float void eeprom_float_example(float value)
{
/* float in EEPROM schreiben */
eeprom_write_float(&eeFloat, value);

/* float aus EEPROM lesen */
return eeprom_read_float(&eeFloat);
}</syntaxhighlight>

=== EEPROM-Speicherabbild in .eep-Datei ===

Mit den zum Compiler gehörenden Werkzeugen kann der aus den Variablendeklarationen abgeleitete EEPROM-Inhalt in eine Datei geschrieben werden. Die übliche Dateiendung ist .eep, Daten im Intel Hex-Format. Damit können Standardwerte für den EEPROM-Inhalt im Quellcode definiert werden.

Makefiles nach WinAVR/MFile-Vorlage enthalten bereits die notwendigen Einstellungen, siehe dazu die Erläuterungen im [[AVR-GCC-Tutorial/Exkurs Makefiles|Exkurs Makefiles]].

Der Inhalt der eep-Datei muss ebenfalls zum Mikrocontroller übertragen werden, wenn die Initialisierungswerte aus der Deklaration vom Programm erwartet werden. Ansonsten enthält der EEPROM-Speicher nach der Übertragung des Programmers mittels ISP abhängig von der Einstellung der EESAVE-Fuse<ref>vgl. Datenblatt Abschnitt Fuse Bits</ref> nicht die korrekten Werte:
; EESAVE = 0 (programmed): Die Daten im EEPROM bleiben erhalten. Werden sie nicht neu geschrieben, so enthält das EEPROM evtl. Daten, die nicht mehr zum Programm passen.
; EESAVE = 1 (unprogrammed): Beim Programmieren werden die Daten im EEPROM gelöscht, also auf 0xff gesetzt.

Als Sicherung kann man im Programm nochmals die Standardwerte vorhalten, beim Lesen auf 0xFF prüfen und gegebenenfalls einen Standardwert nutzen.

=== Direkter Zugriff auf EEPROM-Adressen ===

Will man direkt auf bestimmte EEPROM Adressen zugreifen, dann sind folgende Funktionen hilfreich, um sich die Typecasts zu ersparen:

<syntaxhighlight lang="c">
#include <avr/eeprom.h>

// Byte aus dem EEPROM lesen
uint8_t EEPReadByte(uint16_t addr)
{
return eeprom_read_byte((uint8_t *)addr);
}

// Byte in das EEPROM schreiben
void EEPWriteByte(uint16_t addr, uint8_t val)
{
eeprom_write_byte((uint8_t *)addr, val);
}
</syntaxhighlight>

oder als Makro:

<syntaxhighlight lang="c">
#define EEPReadByte(addr) eeprom_read_byte((uint8_t *)addr)
#define EEPWriteByte(addr, val) eeprom_write_byte((uint8_t *)addr, val)
</syntaxhighlight>

Verwendung:

<syntaxhighlight lang="c">
EEPWriteByte(0x20, 128); // Byte an die Adresse 0x20 schreiben
...
Val=EEPReadByte(0x20); // EEPROM-Wert von Adresse 0x20 lesen
</syntaxhighlight>

=== EEPROM-Register ===
Um das EEPROM anzusteuern, sind drei Register von Bedeutung:
;EEAR: Hier werden die Adressen eingetragen zum Schreiben oder Lesen. Dieses Register unterteilt sich nochmal in EEARH und EEARL, da in einem 8-Bit-Register keine 512 Adressen adressiert werden können.
;EEDR: Hier werden die Daten eingetragen, die geschrieben werden sollen, bzw. es enthält die gelesenen Daten.
;EECR: Ist das Kontrollregister für das EEPROM

Das EECR steuert den Zugriff auf das EEPROM und ist wie folgt aufgebaut:

:{| class="wikitable" style="text-align:center"
|+ '''Aufbau des EECR-Registers'''
|-
!Bit
| 7 || 6 || 5 || 4 || 3 || 2 || 1 || 0
|-
! Name
| - || - || - ||- || EERIE || EEMWE || EEWE || EERE
|-
! Read/Write
| R || R || R || R || R/W || R/W || R/W || R/W
|-
!Init Value
| 0 || 0 || 0 || 0 || 0 || 0 || 0 || 0
|}

'''Bedeutung der Bits'''

;Bit 4-7: nicht belegt

;Bit 3 (EERIE): ''EEPROM Ready Interrupt Enable'': Wenn das Bit gesetzt ist und globale Interrupts erlaubt sind in Register SREG (Bit 7), wird ein Interrupt ausgelöst nach Beendigung des Schreibzyklus (EEPROM Ready Interrupt). Ist einer der beiden Bits 0, wird kein Interrupt ausgelöst.

;Bit 2 EEMWE): ''EEPROM Master Write Enable'': Dieses Bit bestimmt, dass, wenn EEWE = 1 gesetzt wird (innerhalb von 4 Taktzyklen), das EEPROM beschrieben wird mit den Daten in EEDR bei Adresse EEAR. Wenn EEMWE = 0 ist und EEWE = 1 gesetzt wird, hat das keine Auswirkungen. Der Schreibvorgang wird dann nicht ausgelöst. Nach 4 Taktzyklen wird das Bit EEMWE automatisch wieder auf 0 gesetzt. Dieses Bit löst den Schreibvorgang nicht aus, es dient sozusagen als Sicherungsbit für EEWE.

;Bit 1 (EEWE): ''EEPROM Write Enable'': Dieses Bit löst den Schreibvorgang aus, wenn es auf 1 gesetzt wird, sofern vorher EEMWE gesetzt wurde und seitdem nicht mehr als 4 Taktzyklen vergangen sind. Wenn der Schreibvorgang abgeschlossen ist, wird dieses Bit automatisch wieder auf 0 gesetzt und, sofern EERIE gesetzt ist, ein Interrupt ausgelöst. Ein Schreibvorgang sieht typischerweise wie folgt aus:
:# EEPROM-Bereitschaft abwarten (EEWE=0)
:# Adresse übergeben an EEAR
:# Daten übergeben an EEDR
:# Schreibvorgang auslösen in EECR mit Bit EEMWE=1 und EEWE=1
:# (Optional) Warten, bis Schreibvorgang abgeschlossen ist

;Bit 0 EERE: ''EEPROM Read Enable'': Wird dieses Bit auf 1 gesetzt wird das EEPROM an der Adresse in EEAR ausgelesen und die Daten in EEDR gespeichert. Das EEPROM kann nicht ausgelesen werden, wenn bereits eine Schreiboperation gestartet wurde. Es ist daher zu empfehlen, die Bereitschaft vorher zu prüfen. Das EEPROM ist lesebereit, wenn das Bit EEWE=0 ist. Ist der Lesevorgang abgeschlossen, wird das Bit wieder auf 0 gesetzt, und das EEPROM ist für neue Lese- und Schreibbefehle wieder bereit. Ein typischer Lesevorgang kann wie folgt aufgebaut sein:
:# Bereitschaft zum Lesen prüfen (EEWE=0)
:# Adresse übergeben an EEAR
:# Lesezyklus auslösen mit EERE = 1
:# Warten, bis Lesevorgang abgeschlossen EERE = 0
:# Daten abholen aus EEDR

= Die Nutzung von sprintf und printf =

Um komfortabel, d.h. formatiert, Ausgaben auf ein Display oder die serielle Schnittstelle zu tätigen, bieten sich '''sprintf''' oder '''printf''' an. Alle *printf-Varianten sind jedoch ziemlich speicherintensiv und der Einsatz in einem Mikrocontroller mit knappem Speicher muss sorgsam abgewogen werden.

Bei '''sprintf''' wird die Ausgabe zunächst in einem Puffer vorbereitet und anschließend mit einfachen Funktionen zeichenweise ausgegeben. Es liegt in der Verantwortung des Programmierers, genügend Platz im Puffer für die erwarteten Zeichen bereitzuhalten.

<syntaxhighlight lang="c">
#include <stdio.h>
#include <stdint.h>

// ...
// nicht dargestellt: Implementierung von uart_puts (vgl. Abschnitt UART)
// ...

uint16_t counter;

// Ausgabe eines unsigned Integerwertes
void uart_puti( uint16_t value )
{
uint8_t puffer[20];

sprintf( puffer, "Zählerstand: %u", value );
uart_puts( puffer );
}

int main()
{
counter = 5;

uart_puti( counter );
uart_puti( 42 );
}
</syntaxhighlight>

Eine weitere elegante Möglichkeit besteht darin, den STREAM stdout (Standardausgabe) auf eine eigene Ausgabefunktion umzuleiten. Dazu wird dem Ausgabemechanismus der C-Bibliothek eine neue Ausgabefunktion bekannt gemacht, deren Aufgabe es ist, ein einzelnes Zeichen auszugeben. Wohin die Ausgabe dann tatsächlich stattfindet, ist Sache der Ausgabefunktion. Im Beispiel unten wird auf UART ausgegeben. Alle anderen, höheren Funktionen wie z. B. '''printf''', greifen letztendlich auf diese primitive Ausgabefunktion zurück.

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <stdio.h>

void uart_init(void);

// a. Deklaration der primitiven Ausgabefunktion
int uart_putchar(char c, FILE *stream);

// b. Umleiten der Standardausgabe stdout (Teil 1)
static FILE mystdout = FDEV_SETUP_STREAM( uart_putchar, NULL, _FDEV_SETUP_WRITE );

// c. Definition der Ausgabefunktion
int uart_putchar( char c, FILE *stream )
{
if( c == '\n' )
uart_putchar( '\r', stream );

loop_until_bit_is_set( UCSRA, UDRE );
UDR = c;
return 0;
}

void uart_init(void)
{
/* hier µC spezifischen Code zur Initialisierung */
/* des UART einfügen... s.o. im AVR-GCC-Tutorial */

// Beispiel:
//
// myAVR Board 1.5 mit externem Quarz Q1 3,6864 MHz
// 9600 Baud 8N1

#ifndef F_CPU
#define F_CPU 3686400
#endif
#define UART_BAUD_RATE 9600

// Hilfsmakro zur UBRR-Berechnung ("Formel" laut Datenblatt)
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

UCSRB |= (1<<TXEN) | (1<<RXEN); // UART TX und RX einschalten
UCSRC |= (1<<URSEL)|(3<<UCSZ0); // Asynchron 8N1

UBRRH = (uint8_t)( UART_UBRR_CALC( UART_BAUD_RATE, F_CPU ) >> 8 );
UBRRL = (uint8_t)UART_UBRR_CALC( UART_BAUD_RATE, F_CPU );
}

int main(void)
{
int16_t antwort = 42;
uart_init();

// b. Umleiten der Standardausgabe stdout (Teil 2)
stdout = &mystdout;

// Anwendung
printf( "Die Antwort ist %d.\n", antwort );
return 0;
}

// Quelle: avr-libc-user-manual-1.4.3.pdf, S.74
// + Ergänzungen
</syntaxhighlight>

Sollen Fließkommazahlen ausgegeben werden, muss im Makefile eine andere (größere) Version der [[FAQ#Aktivieren_der_Floating_Point_Version_von_sprintf_beim_WinAVR_mit_AVR-Studio|printflib]] eingebunden werden.

= Anmerkungen =
<references/>

= TODO =
* Aktualisierung Register- und Bitbeschreibungen an aktuelle AVR
* "naked"-Funktionen

[[Kategorie:avr-gcc Tutorial| ]]

AVR-Tutorial: Power Management

2015-11-27T14:30:02Z

Kbuchegg: schliessendes Tag nach dem Assembler Beispiel ergänzt

'''ACHTUNG!'''
Dieser Artikel befindet sich noch im Aufbau!

Vorallem in batteriebetriebenen Systemen spielt die Leistungsaufnahme eine wichtige Rolle, d.h. sie soll so niedrig wie möglich gehalten werden um eine lange Laufzeit zu erreichen. Den sparsamen Umgang mit der verfügbaren el. Ladung nennt man '''Power Management''' (dt. Energiesparen).

Im Rahmen des Power Managements stehen uns beispielsweise die Sleep-Modi zur Verfügung, mit denen wir bestimmte Module zeitweise deaktivieren können. Andere garnicht genutzte Module können wir durch entsprechende Konfiguration (z.B. in den Fuses) auch komplett deaktivieren.

== Theorie ==

Der Stromverbrauch einer CMOS-Schaltung (was auch Mikrocontroller sind) hängt letztlich nur davon ab, wie viele Gates bei welcher Spannung umgeladen werden. Zur Reduktion steht demnach zur Verfügung:
* Reduktion der Umladevorgänge pro Sekunde, also Reduktion der Taktfrequenz
* Reduktion der beteiligten Kapazitäten, also Abschalten nicht benutzter Funktionsblöcke
* Reduktion der Speisespannung (bei manchen Controllern ist das die ''Kernspannung'')

Den statischen Reststrom kann man heutzutage vernachlässigen, auch wenn an dieser Stelle die Anmerkung fallen muss, dass AVRs da eher schlecht abschneiden. Hingegen muss Strom durch ohmsche Lasten, etwa Pull-Up-Widerstände oder LEDs, unbedingt beachtet werden! Außerdem dürfen keine offenen (CMOS!-)Eingänge „herumfliegen“ sondern müssen allesamt an definiertem Potenzial liegen. In der Regel können Mikrocontroller unbenutzte Eingänge im Schlafmodus oder Analogeingangsbetrieb automatisch abtrennen.

Grundsätzlich sollte für Stromsparbetrieb die niedrigstmögliche Taktfrequenz gewählt werden, die möglich ist. Übliche Mikrocontroller können direkt von einem Uhrenquarz mit 32,768 kHz gespeist werden. Macht natürlich auch nur maximal 32768 Befehle pro Sekunde. Die Stromaufnahme ist dabei sehr gering und im Gegensatz zu Sleep-Mode-Tricksereien ohne hohe Spitzen.

Da das Antwortverhalten bei derart geringen Taktfrequenzen leidet, wird man eine höhere Frequenz wählen und den Prozessor bei Nicht-Bedarf schlafen schicken. Die Strom-Spitzen sind dementsprechend höher, die Gesamtstromaufnahme bleibt jedoch gering.

Viele Mikrocontroller können einzelne Funktionsblöcke abschalten. Bei den AVRs schlägt da vor allem der 16-Bit-Timer 1 zu Buche. Aber auch die Referenzspannungsquelle für den A/D-Wandler, Analogvergleicher oder den Brown-Out-Detektor kann man abschalten.

Für die Kontrolle der Stromaufnahme aus einer Batterie ist ein Digitalmultimeter mit vielen Strommessbereichen bis 20 µA (Auflösung 10 nA) vorteilhaft. Außerdem ein Plättchen einer doppelseitigen Leiterplatte mit dünnen Drähtchen, das man unter die Batteriekontaktierung schieben kann. Weicht die Stromaufnahme vom Datenblatt ab, hat man wohl noch irgendetwas vergessen.

=== Sleep Modi ===

Welche Sleep-Modi es gibt, hängt vom verwendeten µC ab, dieser Artikel nimmt jedoch Bezug auf den ATmega32. Um einen der verfügbaren Sleep-Modi des ATmega32 zu betreten müssen folgende Schritte ausgeführt werden

# Das SE-Bit im MCUCR-Register wird auf 1 gesetzt
# Die SMx-Bits im MCUCR-Register je nach gewünschtem Modus setzen
# Der SLEEP-Befehl wird ausgeführt

Der Mikrocontroller geht dann sofort in den SLEEP-Modus, d.h. noch vor eventuell anstehenden Interrupts, und wacht erst wieder auf wenn ein Signal eines geeigneten Moduls (je nach Modus) ihn aufweckt.

Die Arbeit wird dann mit der ersten Anweisung hinter dem SLEEP-Befehl wieder aufgenommen.

{| class="wikitable"
|+ MCUCR - MCU Control Register
|- style="text-align:center"
! Bit
| style="width:12%" | 7
| style="width:12%" | 6
| style="width:12%" | 5
| style="width:12%" | 4
| style="width:12%; background-color:#c0c0c0" | 3
| style="width:12%; background-color:#c0c0c0" | 2
| style="width:12%; background-color:#c0c0c0" | 1
| style="width:12%; background-color:#c0c0c0" | 0
|- style="text-align:center"
! Bezeichnung
| SE
| SM2
| SM1
| SM0
| style="background-color:#c0c0c0" | ISC11
| style="background-color:#c0c0c0" | ISC10
| style="background-color:#c0c0c0" | ISC01
| style="background-color:#c0c0c0" | ISC00
|}

;Bit 7 - SE: Sleep Enable
:Mit diesem Bit wird bestimmt ob der Sleep-Befehl ausgeführt wird (1) oder nicht (0).

;Bit 6..4 - SM2..0: Sleep Mode Select
:Mit diesen drei Bits wird der gewünschte Sleep-Modus gewählt

{| class="wikitable"
! SM2
! SM1
! SM0
! style="text-align:left" | Sleep Modus
|- style="text-align:center"
| 0
| 0
| 0
| style="text-align:left" | Idle
|- style="text-align:center"
| 0
| 0
| 1
| style="text-align:left" | ADC Noise Reduction
|- style="text-align:center"
| 0
| 1
| 0
| style="text-align:left" | Power-down
|- style="text-align:center"
| 0
| 1
| 1
| style="text-align:left" | Power-save
|- style="text-align:center"
| 1
| 0
| 0
| style="text-align:left" | Reserved
|- style="text-align:center"
| 1
| 0
| 1
| style="text-align:left" | Reserved
|- style="text-align:center"
| 1
| 1
| 0
| style="text-align:left" | Standby(1)
|- style="text-align:center"
| 1
| 1
| 1
| style="text-align:left" | Extended Standby(1)
|-
|}

(1) Nur verfügbar mit externem Taktgeber

====Modi Übersicht====

Generell ist der Modus zu wählen, der die meisten nicht benötigten Module abschaltet.

{| class="wikitable"
!
! colspan="5" | Aktive Takte
! colspan="2" | Aktive Oszillatoren
! colspan="6" | Weckquellen
|- style="background-color:#f0f0f0"
| Sleep Modus
| clkCPU
| clkFLASH
| clkIO
| clkADC
| clkASY
| Haupttaktgeber
| Timer Oszillator
| INT2 INT1 INT0
| TWI Address Match
| Timer2
| SPM/EEPROM Ready
| ADC
| Andere I/O
|- style="text-align:center"
| style="text-align:left" | Idle
|
|
| x
| x
| x
| x
| x(2)
| x
| x
| x
| x
| x
| x
|- style="text-align:center"
| style="text-align:left" | ADC Noise Reduction
|
|
|
| x
| x
| x
| x(2)
| x(3)
| x
| x
| x
| x
|
|- style="text-align:center"
| style="text-align:left" | Power-down
|
|
|
|
|
|
|
| x(3)
| x
|
|
|
|
|- style="text-align:center"
| style="text-align:left" | Power-save
|
|
|
|
| x(2)
|
| x(2)
| x(3)
| x
| x(2)
|
|
|
|- style="text-align:center"
| style="text-align:left" | Standby(1)
|
|
|
|
|
| x
|
| x(3)
| x
|
|
|
|
|- style="text-align:center"
| style="text-align:left" | Extended Standby(1)
|
|
|
|
| x(2)
| x
| x(2)
| x(3)
| x
| x(2)
|
|
|
|}

(1) Nur verfügbar bei externer Taktquelle 
(2) Wenn AS2-Bit in ASSR-Register gesetzt 
(3) Nur INT2 oder Level Interrupt INT1 und INT0 

=== Manuelles Deaktivieren ===
Einzelne Module können auch manuell deaktviert werden um Strom zu sparen, das bietet sich vorallem an wenn bestimmte Module im gegebenen Projekt generell nicht benötigt werden und damit deaktiviert werden können.

==== Analog to Digital Converter ====
Der ADC ist standardmäßig aktiviert. Um ihn zu deaktivieren, muss man ADEN (Bit 7) im Register ADCSRA auf Null setzen.

==== Analog Comparator ====
Der Analogkomparator ist standardmäßig aktiviert. Um ihn zu deaktivieren, muss man ACD (Bit 7) im Register ACSR setzen.

==== Brown-Out Detector ====
Der Brown-Out Detector lässt sich entweder durch das BODEN-Bit in den Fuses oder mit entsprechenden Befehlen aktivieren oder deaktivieren. Das Fuse-Bit ist standardmäßig gesetzt (Achtung: Umgekehrte Logik!) und der BOD damit deaktiviert.

==== Watchdog ====
Auch der Watchdog-Timer lässt sich in den Fuses standardmäßig aktivieren/deaktivieren, hier über das WDTON-Bit.
Natürlich geht auch das softwareseitig [http://www.mikrocontroller.net/articles/AVR-Tutorial:_Watchdog]

== Praxis ==

=== Assembler ===
Hier mal etwas Code der nicht aufgeräumt ist aber sich gut eignet für Versuche und funktioniert.
Verbesserungen folgen.

<syntaxhighlight lang="asm">
;**********
;* Dateibeschrieb:
;* Interrupttest_Eingängexx.ASM
;* Autor Martin Kuch
;* V02 23.10.2014 mit Sleep und LED Blink in Go raus aus ISR ST:OK!
;* V03 23.10.2014 cli und sei in Go - nur 1x Flanke erkennen nach Schlußdelay ST: OK!
;* V04 23.10.2014 sbic warten bis alle Taster wieder frei sind ST:OK!
;**********
;* Funtionen:
;* 4 Taster an PB0 ... PB3 zur Eingabesteuerung
;* Interrupt 0B (PinChangeInt)
;* PB4 LED
;**********
;* Hardware Zielschaltung:
;* Test-Board mit ATTiny2313 PU
;* Steckernetzgerät Sek: 6VAC 350mA
;* Netzteil eingenbau: Brückengleichrichter, 330uF, 7805CT, 220uF, 6,8nF 2x, LED + 261R
;**********
;* Anschlussschema:
; ATTiny2313
; Port Pin - Pin Funktion
; PB1 12 - Eingang Schalter 1 mit Pullup(+LED) gegen Masse (Set)
; PB2 13 - Eingang Schalter 2 mit Pullup(+LED) gegen Masse (Back)
; PB3 14 - Eingang Schalter 3 " (vor)
; PB4 15 - Eingang Schalter 4 " (zurück)
; PB0 16 - Ausgang Lüfter Ein, LED mit Widerstand gegen +5VDC (Kathode gegen Ausgang)

;* Controllertyp
.device ATtiny2313 ;für Gasm .include Headerdatei für at2313.asm bei Gasm nicht nötig
;* Definitionen
.def temp1 = r16 ;Allzweckregister und für LCD_Routines3
.def temp2 = r17 ;für LCD_Routines
.def temp3 = r18 ;für LCD_Routines
.def TM = r19 ;Allzweckregister Programm
.def TM1 = r20 ;Allzweckregister 2
.def TMz = r21 ;Zähler allg.
.def Ct0 = r24 ;Couter Delay Vorgabe, Übergabewert für Zeitschleife
.def Ct1 = r25 ;Conter Delay intern

;* Flash Programm
.cseg ;Flash Segment
; Interrupt-Handler
.org 0x0000
rjmp Main ;0x00 Reset
reti;rjmp SInt ;0x01 INT0 PD2 (6)
reti;rjmp SInt ;0x02 INT1 PD3 (7)
reti;rjmp SInt ;0x03 Tim1_Capt
reti;rjmp SInt ;0x04 Tim1_CompA
reti;rjmp SInt ;0x05 Tim1_OVF
reti;rjmp SInt ;0x06 Tim0_OVF
reti;rjmp SInt ;0x07 Uart0_rxc
reti;rjmp SInt ;0x08 Uart0_dre
reti;rjmp SInt ;0x09 Uart0_txc
reti;rjmp SInt ;0x0A ANA_Comp
rjmp IntPC ;0x0B PinChangeInt
reti;rjmp SInt ;0x0C Tim1_CompB
reti;rjmp SInt ;0x0D Tim0_CompA
reti;rjmp SInt ;0x0E Tim0_CompB
reti;rjmp SInt ;0x0F USI_Start
reti;rjmp SInt ;0x10 USI_OVERFLOW
reti;rjmp SInt ;0x11 EE_READ
reti;rjmp SInt ;0x12 WDT_OVERFLOW
nop

;* Main Programm Endlos Steuerung Taster
Main:
;Stack init
ldi TM, RAMEND
out SPL, TM
;*Init
ldi TM, 0b00010000 ;Port B Bit0...3 => Eingang B4 => Ausgang
out DDRB, TM
nop
;*Hallo blinken testen, LED-Test und schauen ob uC läuft
cbi PortB,4 ;LED an
ldi Ct0, 100
rcall delayms
sbi PortB,4 ;LED aus
rcall delayms
ldi Ct0, 255

;*Init Interrupt PCINT
ldi TM, 0b00100000 ;=32 dez.
out MCUCR, TM ;Bit5 = EN enable Sleep
out GIMSK, TM ;PCIE PC.Int.Enable
ldi TM, 0b00001111
out PCMSK, TM ;Maske Int. Pin zulassen
sei ;Interrupts zulassen
Go:
sleep ;Schlafen legen = Energiesparen
nop
cli
cbi PortB,4 ;LED an
rcall delayms

Go_1:
sbis PINB,0 ;Taste noch gedrückt? = 0 => warten
rjmp Go_1
sbis PINB,1 ;Taste noch gedrückt? = 0 => warten
rjmp Go_1
sbis PINB,2 ;Taste noch gedrückt? = 0 => warten
rjmp Go_1
sbis PINB,3 ;Taste noch gedrückt? = 0 => warten
rjmp Go_1

sbi PortB,4 ;LED aus
; rcall delayms
sei ;Interrupts einschalten
rjmp Go

;*ISR für PinChangeInt. (0x0B)
IntPC:
; push TM
; in TM, SREG
nop
; out SREG, TM
; pop TM
reti

; Pause Count * 5ms
delayms:
mov Ct1, Ct0
delayms_:
rcall delay5ms
dec Ct1
brne delayms_
ret

; Längere Pause für manche Befehle
delay5ms: ; 5ms Pause
Push temp2
ldi temp1, ( XTAL * 5 / 607 ) / 1000
WGLOOP0: ldi temp2, $C9
WGLOOP1: dec temp2
brne WGLOOP1
dec temp1
brne WGLOOP0
pop temp2
ret ; wieder zurück
</syntaxhighlight>

=== C ===

Ein simples Testprogramm, um mit sleep modi im AVR zu spielen. Es funktioniert sehr gut mit dem ATmega8 und ist auch auf andere AVRs portierbar. Teilweise sind weitere Modi verfügbar.

Wichtig ist, daß die Interruptroutine für den "Weckruf" vorhanden sein muss. Es müssen nicht zwingend Aktionen in ihr durchgeführt werden.

<syntaxhighlight lang="c">
/* ATmega8 with internal 4Mhz clock (6cycle + 64ms) */

#include <avr/io.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <util/delay.h>

int main(void)
{
DDRC |= (1 << PC2) | (1 << PC1); // leds for testing

DDRD &= ~(1 << PD2); // INT0: input...
PORTD |= (1 << PD2); // ...with pullup.

// level interrupt INT0 (low level)
MCUCR &= ~((1 << ISC01) | (1 << ISC00));

// infinite main loop
while (1)
{
// trigger leds for testing
PORTC ^= (1 << PC1);
_delay_ms(500);
PORTC ^= (1 << PC1);

// enable external interrupt
GICR |= (1 << INT0);

// set sleep mode
set_sleep_mode(SLEEP_MODE_PWR_DOWN);

// sleep_mode() has a possible race condition
sleep_enable();
sei();
sleep_cpu();
sleep_disable();

// waking up...
// disable external interrupt here, in case the external low pulse is too long
GICR &= ~(1 << INT0);

// disable all interrupts
cli();
}
}

ISR(INT0_vect)
{
// ISR might be empty, but is necessary nonetheless
PORTC ^= (1 << PC2); // debugging
}
</syntaxhighlight>

== Quellen ==
[http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf ATMEL AVR ATmega32 Datenblatt]

----
{{Navigation_zurückhoch|
zurücktext=Power Management|
zurücklink=AVR-Tutorial: Power Management|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial}}

[[Kategorie: AVR-Tutorial|Power Management]]

Serial Peripheral Interface

2015-09-29T17:41:06Z

Kbuchegg:

Das '''S'''erial '''P'''eripheral '''I'''nterface, kurz SPI oder auch Microwire genannt, ist ein Bus-System bestehend aus drei Leitungen für eine serielle synchrone Datenübertragung zwischen verschiedenen ICs.

Der Bus besteht aus folgenden Leitungen
* MOSI ('''M'''aster '''O'''ut -> '''S'''lave '''I'''n) auch SDO ('''S'''erial '''D'''ata '''O'''ut) oder DO
* MISO ('''M'''aster '''I'''n <- '''S'''lave '''O'''ut) auch SDI ('''S'''erial '''D'''ata '''I'''n) oder DI
* SCK (Serial Clock) - Schiebetakt

Zusätzlich zu diesen drei Leitungen wird für jeden Slave eine Slave Select (SS) oder auch Chip Select (CS) genannte Leitung benötigt, durch die der Master den Slave zur aktuellen Kommunikation selektiert. Dies geschieht dadurch, dass der Master die SS/CS-Leitung von High nach Low zieht. Oft ist mit dieser Aktivierung durch den Master auch eine Benachrichtigung für den Slave verbunden mit der ihm mitgeteilt wird, dass jetzt eine Nachricht beginnt, das nächste Byte also zum Beispiel als Kommando aufzufassen ist.

Die Übertragung geschieht so, dass der Master seine Datenleitung (MOSI) auf den Pegel des nächsten Bits bringt und dann an der SCK Leitung einen Puls ausgibt. Gleichzeitig wird vom Master der Pegel an der Datenleitung vom Slave zum Master überwacht und ihr Zustand als nächstes einzulesendes Bit aufgefasst. Üblicherweise gibt es zumindest beim Master mehrere Einstellungen, die festlegen, welches der Grundzustand dieser SCK Leitung sein soll und welche Flanke des Clock-Pulses zur Datenübernahme herzunehmen ist (die steigende oder die fallende). Bei einigen Slaves ist diese Einstellung ebenfalls möglich, oft ist es aber so, dass per SPI anzusprechende IC eine fixe Einstellung benutzen, an die sich der Master anpassen muss.

Für den SPI-Bus gibt es kein festgelegtes Protokoll. Die Clock-Polarität (CPOL) und Phase (CPHA) können ebenfalls von Slave zu Slave unterschiedlich sein. Der SPI-Bus kann mit einer Taktfrequenz von mehreren Megahertz betrieben werden. Es gibt viele verschiedene ICs die als Slave an dem SPI-Bus betrieben werden können, diese gehen von einfachen Schieberegistern bis hin zu RTCs oder Displaytreibern mit vorgegebenem Protokoll. Unter anderem werden die meisten [[AVR]]-Microcontroller von Atmel über SPI [[ISP|programmiert]], siehe dazu [[AVR In System Programmer]].

== konzeptionelles Übertragungsprinzip ==

Bei SPI verlieren die Begriffe 'Sender' und 'Empfänger' ihre Bedeutung. Das Übertragungsprinzip funktioniert so, dass gleichzeitig 1 Byte vom Master zum Slave und 1 Byte vom Slave zum Master übertragen wird. Die Übertragung ist als eher mit dem Begriff "Austausch von Bytes" zu beschreiben, als dass es sich um ein Senden bzw. Empfangen handelt. Je nach Sichtweise könnte man auch sagen, dass sowohl Master als auch Slave jederzeit sowohl Sender als auch Empfänger sind. Der einzige Unterschied zwischen den Busteilnehmern besteht darin, dass beim SPI Bus jegliche Kommunikation immer vom Master ausgeht. Er hat die Verwaltung der SCK Leitung inne und wenn der Master keine SCK Pulse generiert, dann kann ein Slave auch nichts übertragen. Die Generierung der SCK Pulse wird dabei üblicherweise dadurch angestossen, dass der Master einfach angewiesen wird, 1 Byte über SPI auszugeben. Weiters kann ein Slave auch eine SPI Übertragung nicht hinauszögern. Wenn vom Master die SCK Pulse kommen, dann muss ein Slave die MISO Leitung bedienen. Er hat keine Möglichkeit dies nicht zu tun, selbst wenn er noch gar kein Ergebnis für den Master vorliegen hat. Selbst wenn der Slave die MISO Leitung nicht bedient, der Master wird zum per Modus eingestellten Zeitpunkt die Polarität der MISO Leitung auswerten und sich daraus das nächste Bit bestimmen.

Erfolgt eine Abfrage eines Masters an einen Slave dergestalt, dass der Master ein Kommando an den Slave sendet, auf das der Slave mit einem Ergebnis zu antworten hat, dann sind dazu immer mindestens 2 Übertragungen notwendig. Im ersten Byte-Austausch übermittelt der Master sein Kommando an den Slave (der zu diesem Zeitpunkt logischerweise noch kein Ergebnis vorliegen haben wird, er kennt ja das Kommando noch nicht) und im zweiten Byte-Austausch überträgt der Master einfach nur 1 Byte (meistens genügt da einfach irgendein Bytewert) um dem Slave seinerseits Gelegenheit zu geben, das zuvor angefragte Ergebnis zum Master zu übertragen. Beachten sollte man, dass ein Slave auch des öfteren etwas Zeit benötigen wird, um ein gerade erhaltenes Kommando auszuwerten und die entsprechenden Ergebnisse bereit zu stellen. Ein Master wird also gut daran tun, nach dem Byteaustausch zum Zwecke der Kommandoübermittlung eine kleine Pause einzulegen, ehe er dann mit dem zweiten Byteaustausch das Ergbnis abholt.

== SPI-Modi ==

Wie schon angesprochen gibt es für das SPI verschiedene Möglichkeiten Polarität und Phase des Taktes einzustellen. Folgende vier Modi sind möglich:

{| border="1"
!Mode
!CPOL
!CPHA
|-
|0 ||0 ||0
|-
|1 ||0 ||1
|-
|2 ||1 ||0
|-
|3 ||1 ||1
|}

;CPOL (Clock Polarity)
:0: Takt ist in Ruhe LOW, ein Wechsel auf HIGH zählt als steigende Taktflanke
:1: Takt ist invertiert: in Ruhe HIGH, ein Wechsel auf LOW zählt als steigende Taktflanke
;CPHA (Clock Phase)
:0: Daten werden bei steigender Taktflanke (=abh. von CPOL) eingelesen, bei fallender ausgegeben
:1: Daten werden bei fallender Taktflanke eingelesen, bei steigender ausgegeben

Man sieht, dass Mode 0 und Mode 3 bzw. Mode 1 und Mode 2 jeweils fast identisch sind. Der einzige Unterschied ist der Pegel des Taktes in Ruhe. In der Regel sind diese Modi deshalb austauschbar.

CPOL und CPHA lassen sich in den Konfigurationsregistern des Controllers einstellen. Beim [[AT91SAM]] hat sich Atmel ein kleines Extra einfallen lassen: hier heißt das Bit zur Einstellung der Clock Phase "NCPHA" und entspricht genau dem invertierten Wert von CPHA.

Es ist problemlos möglich ICs mit verschiedenen SPI-Modi an einem Bus zu betreiben, man muss nur vor dem Aktivieren des Chip Select den jeweils richtigen Modus einstellen.

== Falle bei AVR Prozessoren ==

Bei den AVR Prozessoren, die eine SPI Enheit besitzen, ist es eine gute Idee, den SS-Pin der SPI Einheit auf Ausgang zu setzen, wenn man den Prozessor als Master benutzen möchte. Dies geschieht nicht automatisch, da ein auf Eingang geschalteter Pin im Multimaster Modus benötigt wird. Da dieser Fall aber recht selten vorkommt, wird er hier ignoriert. Schaltet man den Pin nicht auf Ausgang, dann hängt es vom extern angelegten Pegel ab, ob der die Master-SPI Einheit arbeitet oder nicht. Daher den Pin immer auf Ausgang schalten. In diesem Fall ist der Pegel der SS Leitung dann irrelevant, die SPI Einheit arbeitet immer, sobald sie als Master konfiguriert wurde.

== Fehlersuche ==

Immer wieder kommt es zu Problemen bei der Nutzung von SPI, obwohl diese Schnittstelle recht einfach aufgebaut ist. Immer wieder kommt es u.a. zu dem Effekt, dass nur bestimmte SPI-Frequenzen funktionieren, etwas höher oder niedrigere nicht. Das ist ein klares Zeichen für Fehler. Folgende Punkte sollte man mit dem [[Oszilloskop]] prüfen.

* Stimmt jeweils der SPI-Modus?
* Sind die Select-Signale vorhanden?
* Sind die erreichten Pegel ausreichend?
* Sind die Clock-Flanken sauber genug? Siehe [[Wellenwiderstand]].
* Sind die Daten während der Datenübernahme stabil?
* Ist die Zeit zwischen Select-Signal und Übertragungsbeginn ausreichend?

== Siehe auch ==
* [[Porterweiterung mit SPI]]
* [[AVR-Tutorial: Schieberegister]]
* [[MMC- und SD-Karten]]
* [http://www.mikrocontroller.net/topic/54441 SPI Codetuning]
* [[SPI Daisychain]]

== Weblinks ==
* http://www.mct.net/faq/spi.html (Clock-Einstellungen, Slave-IC Liste, etc.)
* http://www.matuschek.net/atmega-spi (ATMega SPI Performance Tuning)
* [http://www.atmel.com/dyn/resources/prod_documents/doc2585.pdf AVR151: Setup And Use of The SPI] Atmel Application Note (PDF)
* [http://www.atmel.com/dyn/resources/prod_documents/AVR151.zip AVR151: Examples for Setup and use of the SPI] Programming Examples for the Atmel Application Note (zip)

[[Kategorie:SPI| ]]

AVR-Tutorial: UART

2015-08-25T12:09:52Z

Kbuchegg: /* Hardware Handshake */

Wie viele andere Controller besitzen die meisten AVRs einen '''[[UART]]''' ('''U'''niversal '''A'''synchronous '''R'''eceiver and '''T'''ransmitter). Das ist eine serielle Schnittstelle, die meistens zur Datenübertragung zwischen Mikrocontroller und PC genutzt wird. Zur Übertragung werden zwei Pins am Controller benötigt: '''TXD''' und '''RXD'''. Über '''TXD''' ("Transmit Data") werden Daten gesendet, '''RXD''' ("Receive Data") dient zum Empfang von Daten.

== Hardware ==

Um den UART des Mikrocontrollers zu verwenden, muss der Versuchsaufbau um folgende Bauteile erweitert werden:

[[Bild:AVR-RS232.png|framed|right|640px| UART/MAX232 Standardbeschaltung ]]

Auf dem Board vom [http://shop.mikrocontroller.net/ Shop] sind diese Bauteile bereits enthalten, man muss nur noch die Verbindungen zwischen MAX232 (IC2) und AVR herstellen wie im [http://shop.mikrocontroller.net/images/avrplat28-app.jpg Bild] zu sehen.

* Der MAX232 ist ein [[Pegelwandler]], der die -12V/+12V Signale an der seriellen Schnittstelle des PCs zu den 5V/0V des AVRs kompatibel macht.
* C1 ist ein kleiner Elektrolyt-, Tantal- oder Keramikkondensator, wie er immer wieder zur Entkopplung der Versorgungsspannungen an digitalen ICs verwendet wird.
* Die vier Kondensatoren C2..C5 sind Elektrolyt-, Tantal- oder Keramikkondensatoren. Falls Elkos oder Tantals verwendet werden, auf die richtige Polung achten! Der exakte Wert ist hier relativ unkritisch, in der Praxis sollte alles von ca. 1µF bis 47µF mit einer Spannungsfestigkeit von 16V und höher funktionieren.
* X1 ist ein weiblicher 9-poliger SUB-D-Verbinder.
* Die Verbindung zwischen PC und Mikrocontroller erfolgt über ein 9-poliges Modem-Kabel (also ein ''Verlängerungskabel'', '''kein [http://de.wikipedia.org/wiki/Nullmodem-Kabel Nullmodem]-Kabel!)''', das an den seriellen Port des PCs angeschlossen wird. Bei einem Modem-Kabel sind die Pins 2 und 3 des einen Kabelendes mit den Pins 2 und 3 des anderen Kabelendes durchverbunden. Bei einem Nullmodem-Kabel sind die Leitungen gekreuzt, sodass Pin 2 von der einen Seite mit Pin 3 auf der anderen Seite verbunden ist und umgekehrt.
* Als Faustregel kann man annehmen: Befinden sich an den beiden Enden des Kabels die gleiche Art von Anschlüssen (Männchen = Stecker; Weibchen = Buchse), dann benötigt man ein gekreuztes, also ein Nullmodem-Kabel. Am PC-Anschluss selbst befindet sich ein Stecker, also ein Männchen, sodaß am Kabel auf dieser Seite eine Buchse (also ein Weibchen) sitzen muss. Da am AVR laut obigem Schaltbild eine Buchse verbaut wird, muss daher an diesem Ende des Kabels ein Stecker sitzen. Das Kabel hat daher an einem Ende einen Stecker und am anderen Ende eine Buchse und ist daher ein normales Modem-Kabel ( = nicht gekreuzt).

[[Bild:USART_Kabel.gif|framed|center| Kabelbeschaltungen]]

== Software ==

=== UART konfigurieren ===

Als erstes muss die gewünschte Baudrate im Register '''UBRR''' festgelegt werden. Der in dieses Register zu schreibende Wert errechnet sich nach der folgenden Formel:

<math>\text{UBRR} = \frac {\text{Taktfrequenz (in Hz)}} { 16 \cdot \text{Baudrate} } - 1</math>

Beim AT90S4433 kann man den Wert direkt in das Register '''UBRR''' laden, beim ATmega8 gibt es für '''UBRR''' zwei Register: '''UBRRL''' (Low-Byte) und '''UBRRH''' (High-Byte). Bei Baudraten über etwa 3900 Bit/s (gilt nur bei Verwendung eines Takts von 16 MHz) steht in '''UBRRH''' 0, da der berechnete Wert kleiner als 256 ist und somit in '''UBRRL''' alleine passt. Beachtet werden muss, dass das Register '''UBRRH''' vor dem Register '''UBRRL''' beschrieben werden muss. Der Schreibzugriff auf '''UBRRL''' löst das Neusetzen des internen Taktteilers aus.

'''WICHTIGER HINWEIS 1'''

Es empfiehlt sich statt der oben genannten Formel, die Formel der Codebeispiele zu verwenden:

<math>\text{UBRR} = \frac{\text{Taktfrequenz (in Hz)} + (\text{Baudrate} \cdot 8)}{(\text{Baudrate} \cdot 16)}-1 \quad \left( = \frac{ \text{Taktfrequenz (in Hz)} }{ 16 \cdot \text{Baudrate} } -0.5 \right)</math>

Beispiel: Bei einem ATMega mit 16MHz und 115200 Baud ist der Wert laut Datenblatt UBBRL=8. Rechnet man mit der Formel UBRRL=(F_CPU / (UART_BAUDRATE* 16L) - 1) ergibt sich ein Wert von 7,680555 und im UBRRL Register steht somit eine 7 statt einer 8. Die Verwendung der Formel aus dem Codebeispiel ergibt 8.180555 und im UBRRL Register steht somit der richtige Wert - nämlich 8

----

'''WICHTIGER HINWEIS 2'''

Auf Grund permanent wiederkehrender Nachfrage sei hier '''AUSDRÜCKLICH''' darauf hingewiesen, dass bei Verwendung des UART im asynchronen Modus dringend ein Quarz oder Quarzoszillator verwendet werden sollte! Der interne RC-Oszillator der AVRs ist recht ungenau! Damit kann es in Ausnahmefällen funktionieren, muss es aber nicht! Auch ist der interne Oszillator temperaturempfindlich. Damit hat man dann den schönen Effekt, dass eine UART-Schaltung die im Winter noch funktionierte, im Sommer den Dienst verweigert.

Außerdem muss bei der Berechnung von '''UBRR''' geprüft werden, ob mit der verwendeten Taktfrequenz die gewünschte Baudrate mit einem Fehler von <1% generiert werden kann. Das Datenblatt bietet hier sowohl die Formel als auch Tabellen unter der Überschrift des U(S)ART an.

<math> \text{Fehler}_{\text{Baudrate}}[%] = \left( \frac{\text{UBRR}_{\text{gerundet}}+1}{\text{UBRR}_{\text{genau}}+1} -1 \right) \cdot 100</math>

Siehe auch [[Baudratenquarz]]

Wer es ganz einfach haben will, nimmt die folgenden Macros. Die rechnen sogar den Fehler aus und brechen die Assemblierung ggf. ab. Das ist dann praktisch idiotensicher.

<syntaxhighlight lang="avrasm">
.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille

.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif
</syntaxhighlight>

Wer dennoch den internen RC-Oszillator verwenden will, muss diesen kalibrieren. Näheres findet man dazu im Datenblatt, Stichwort Register OSCCAL.
----

Um den Sendekanal des UART zu aktivieren, muss das Bit '''TXEN''' im UART Control Register '''UCSRB''' auf 1 gesetzt werden.

Danach kann das zu sendende Byte in das Register '''UDR''' eingeschrieben werden - vorher muss jedoch sichergestellt werden, dass das Register leer ist, die vorhergehende Übertragung also schon abgeschlossen wurde. Dazu wird getestet, ob das Bit '''UDRE''' ("UART Data Register Empty") im Register '''UCSRA''' auf 1 ist.

Genaueres über die UART-Register findet man im Datenblatt des Controllers.

An dieser Stelle sei noch folgendes angemerkt: Das '''UDRE'''-Bit sagt nichts darüber aus, ob der Controller immer noch damit beschäftigt ist, Daten zu senden. Da das Senderegister mehrfach gepuffert ist, wird '''UDRE''' bereits gesetzt, obwohl das letzte Zeichen den AVR noch nicht komplett verlassen hat. Dies kann insbesondere bei der Verwendung von Sleep-Modes ein Problem werden, wenn der Controller schlafen gelegt wird, bevor das letzte Zeichen versendet wurde, da dies gezwungenermassen zu einem Frame-Error beim Empfänger führen wird. Um sicher zu gehen, dass der UART nicht mehr beschäftigt ist, kann das Bit '''TXC''' ("UART Transmit complete") getestet werden. Dieses wird jedoch wirklich erst nach dem Senden eines Zeichens gesetzt, beinhaltet also auch nach dem Systemstart eine 0, obwohl der Controller nichts sendet.

Der ATmega8 bietet noch viele weitere Optionen zur Konfiguration des UARTs, aber für die Datenübertragung zum PC sind im Normalfall keine anderen Einstellungen notwendig.

=== Senden von Zeichen ===

Das Beispielprogramm überträgt die Zeichenkette "Test!" in einer Endlosschleife an den PC.

'''Hinweis'''

Wenn man das nachfolgende Programm laufen lässt und Hyperterminal startet, scheint es problemlos zu funktionieren. Wenn man aber das RS232 Kabel zwischenzeitlich abzieht und wieder ansteckt wird es oft passieren, dass nur noch wirre Zeichen auf dem PC erscheinen. Das liegt daran, dass der PC aus einem ununterbrochen Zeichenstrom nicht den Anfang eines Zeichens erkennen kann. Darum muss in solchen Fällen periodisch eine kleine Pause von der Länge mindestens eines Zeichens eingelegt werden, damit der PC sich wieder synchronisieren kann.

Die folgenden Beispiele sind für den ATmega8 geschrieben.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16 ; Register für kleinere Arbeiten
.def zeichen = r17 ; in diesem Register wird das Zeichen an die
; Ausgabefunktion übergeben

.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille

.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif

; Stackpointer initialisieren

ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp

; Baudrate einstellen

ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp

; Frame-Format: 8 Bit

ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp

sbi UCSRB,TXEN ; TX aktivieren

loop:
ldi zeichen, 'T'
rcall serout ; Unterprogramm aufrufen
ldi zeichen, 'e'
rcall serout ; Unterprogramm aufrufen
ldi zeichen, 's'
rcall serout ; ...
ldi zeichen, 't'
rcall serout
ldi zeichen, '!'
rcall serout
ldi zeichen, 10
rcall serout
ldi zeichen, 13
rcall serout
rcall sync
rjmp loop

serout:
sbis UCSRA,UDRE ; Warten bis UDR für das nächste
; Byte bereit ist
rjmp serout
out UDR, zeichen
ret ; zurück zum Hauptprogramm

; kleine Pause zum Synchronisieren des Empfängers, falls zwischenzeitlich
; das Kabel getrennt wurde

sync:
ldi r16,0
sync_1:
ldi r17,0
sync_loop:
dec r17
brne sync_loop
dec r16
brne sync_1
ret
</syntaxhighlight>

<div style="float:right; argin:1em">
http://www.mikrocontroller.net/images/hyperterminal.gif
</div>
Der Befehl '''rcall serout''' ruft ein kleines Unterprogramm auf, das zuerst wartet bis das Datenregister '''UDR''' von der vorhergehenden Übertragung frei ist, und anschließend das in zeichen (=r17) gespeicherte Byte an '''UDR''' ausgibt.

Bevor serout aufgerufen wird, wird zeichen jedesmal mit dem ASCII-Code des zu übertragenden Zeichens geladen (so wie in Teil 4 bei der LCD-Ansteuerung). Der Assembler wandelt Zeichen in einfachen Anführungsstrichen automatisch in den entsprechenden ASCII-Wert um. Nach dem Wort "Test!" werden noch die Codes 10 (New Line) und 13 (Carriage Return) gesendet, um dem Terminalprogramm mitzuteilen, dass eine neue Zeile beginnt.

Eine Übersicht aller ASCII-Codes gibt es auf [http://www.asciitable.com/ www.asciitable.com].

Die Berechnung der Baudrate wird übrigens nicht im Controller während der Programmausführung durchgeführt, sondern schon beim Assemblieren, wie man beim Betrachten der Listingdatei feststellen kann.

Zum Empfang muss auf dem PC ein Terminal-Programm wie z. B. HyperTerminal gestartet werden. Der folgende Screenshot zeigt, welche Einstellungen im Programm vorgenommen werden müssen:

Linux-Benutzer können das entsprechende Device (z. B. /dev/ttyS0) mit stty konfigurieren und mit cat die empfangenen Daten anzeigen oder ein Terminalprogramm wie minicom nutzen.

Alternativ kann unter Windows und Linux [http://www.der-hammer.info/terminal/ HTerm] genutzt werden. (Freeware)

{{Clear}}

=== Senden von Zeichenketten ===

Eine bequemere Methode um längere Zeichenketten (Strings) zu übertragen ist hier zu sehen. Dabei werden die Zeichenketten im Flash gespeichert. Als Abschluss des Strings wird der Wert 0x00 genutzt, so wie auch in der Programmiersprache C.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16 ; Register für kleinere Arbeiten
.def zeichen = r17 ; in diesem Register wird das Zeichen an die
; Ausgabefunktion übergeben

.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille

.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif

; hier geht unser Programm los

; Stackpointer initialisieren

ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp

; Baudrate einstellen

ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp

; Frame-Format: 8 Bit

ldi temp, (1<<URSEL)|(3<<UCSZ0)
out UCSRC, temp

sbi UCSRB,TXEN ; TX aktivieren

loop:
ldi zl,low(my_string*2); ; Z Pointer laden
ldi zh,high(my_string*2);
rcall serout_string
rjmp loop

; Ausgabe eines Strings aus dem Flash

serout_string:
lpm ; nächstes Byte aus dem Flash laden
and r0,r0 ; = Null?
breq serout_string_ende ; wenn ja, -> Ende
serout_string_wait:
sbis UCSRA,UDRE ; Warten bis UDR für das nächste
; Byte bereit ist
rjmp serout_string_wait
out UDR, r0
adiw zl:zh,1 ; Zeiger erhöhen
rjmp serout_string ; nächstes Zeichen bearbeiten
serout_string_ende:
ret ; zurück zum Hauptprogramm

; Hier wird jetzt der String definiert und im Flash gespeichert

my_string: .db "Test!",10,13,0
</syntaxhighlight>

=== Empfangen von Zeichen per Polling===

Der AVR kann nicht nur Daten seriell senden, sondern auch empfangen. Dazu muss man, nachdem die Baudrate wie oben beschrieben eingestellt wurde, das Bit '''RXEN''' setzen.

Sobald der UART ein Byte über die serielle Verbindung empfangen hat, wird das Bit '''RXC''' im Register '''UCSRA''' gesetzt, um anzuzeigen, dass ein Byte im Register '''UDR''' zur Weiterverarbeitung bereitsteht. Sobald es aus '''UDR''' gelesen wurde, wird '''RXC''' automatisch wieder gelöscht, bis das nächste Byte angekommen ist.

Das erste einfache Testprogramm soll das empfangene Byte auf den an Port D angeschlossenen LEDs ausgeben. Dabei sollte man daran denken, dass PD0 (RXD) bereits für die Datenübertragung zuständig ist, so dass das entsprechende Bit im Register PORTD keine Funktion hat und damit auch nicht für die Datenanzeige verwendet werden kann.

Nachdem der UART konfiguriert ist, wartet das Programm einfach in der Hauptschleife darauf, dass ein Byte über den UART ankommt (z. B. indem man im Terminalprogramm ein Zeichen eingibt), also '''RXC''' gesetzt wird. Sobald das passiert, wird das Register '''UDR''', in dem die empfangenen Daten stehen, nach temp eingelesen und an den Port D ausgegeben.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = R16

.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille

.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif

; Stackpointer initialisieren

ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp

; Port D = Ausgang

ldi temp, 0xFF
out DDRD, temp

; Baudrate einstellen

ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp

; Frame-Format: 8 Bit

ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp

sbi UCSRB, RXEN ; RX (Empfang) aktivieren

receive_loop:
sbis UCSRA, RXC ; warten bis ein Byte angekommen ist
rjmp receive_loop
in temp, UDR ; empfangenes Byte nach temp kopieren
out PORTD, temp ; und an Port D ausgeben.
rjmp receive_loop ; zurück zum Hauptprogramm
</syntaxhighlight>

=== Empfangen von Zeichen per Interrupt ===

Dieses Programm lässt sich allerdings noch verfeinern. Statt in der Hauptschleife auf die Daten zu warten, kann man auch veranlassen dass ein Interrupt ausgelöst wird, sobald ein Byte angekommen ist. Das sieht in der einfachsten Form so aus:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = R16

.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille

.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif

.org 0x00
rjmp main

.org URXCaddr ; Interruptvektor für UART-Empfang
rjmp int_rxc

; Hauptprogramm

main:

; Stackpointer initialisieren

ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp

; Port D = Ausgang

ldi temp, 0xFF
out DDRD, temp

; Baudrate einstellen

ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp

; Frame-Format: 8 Bit

ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp

sbi UCSRB, RXCIE ; Interrupt bei Empfang
sbi UCSRB, RXEN ; RX (Empfang) aktivieren

sei ; Interrupts global aktivieren

loop:
rjmp loop ; Endlosschleife

; Interruptroutine: wird ausgeführt sobald ein Byte über das UART empfangen wurde

int_rxc:
push temp ; temp auf dem Stack sichern
in temp, UDR ; empfangenes Byte lesen,
; dadurch wird auch der Interrupt gelöscht
out PORTD, temp ; Daten ausgeben
pop temp ; temp wiederherstellen
reti ; Interrupt beenden
</syntaxhighlight>

Diese Methode hat den großen Vorteil, dass das Hauptprogramm (hier nur eine leere Endlosschleife) andere Dinge erledigen kann, während der Controller Daten empfängt. Auf diese Weise kann man mehrere Aktionen quasi gleichzeitig ausführen, da das Hauptprogramm nur kurz unterbrochen wird, um die empfangenen Daten zu verarbeiten.

Probleme können allerdings auftreten, wenn in der Interruptroutine die gleichen Register verwendet werden wie im Hauptprogramm, da dieses ja an beliebigen Stellen durch den Interrupt unterbrochen werden kann. Damit sich aus der Sicht der Hauptschleife durch den Interruptaufruf nichts ändert, müssen alle in der Interruptroutine geänderten Register am Anfang der Routine gesichert und am Ende wiederhergestellt werden. Das gilt vor allem für das CPU-Statusregister ('''SREG''')! Sobald ein einziger Befehl im Interrupt ein einziges Bit im SREG beeinflusst, muss das SREG gesichert werden. Das ist praktisch fast immer der Fall, nur in dem ganz einfachen Beispiel oben ist es überflüssig, weil die verwendeten Befehle das SREG nicht beeinflussen. In diesem Zusammenhang wird der [[Stack]] wieder interessant. Um die Register zu sichern, kann man sie mit '''push''' oben auf den Stapel legen und am Ende wieder in der umgekehrten Reihenfolge(!) mit '''pop''' vom Stapel herunternehmen.

Im folgenden Beispielprogramm werden die empfangenen Daten nun nicht mehr komplett angezeigt. Stattdessen kann man durch Eingabe einer 1 oder einer 0 im Terminalprogramm eine LED (an PB0) an- oder ausschalten. Dazu wird das empfangene Byte in der Interruptroutine mit den entsprechenden ASCII-Codes der Zeichen 1 und 0 (siehe [http://www.asciitable.com/ www.asciitable.com]) verglichen.

Für den [[AVR-Tutorial:_Vergleiche|Vergleich]] eines Registers mit einer Konstanten gibt es den Befehl '''cpi register, konstante'''. Das Ergebnis dieses Vergleichs kann man mit den Befehlen '''breq label''' (springe zu label, wenn gleich) und '''brne label''' (springe zu label, wenn ungleich) auswerten.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = R16

.equ F_CPU = 4000000 ; Systemtakt in Hz
.equ BAUD = 9600 ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille

.if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler
.error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif

.org 0x00
rjmp main

.org URXCaddr
rjmp int_rxc

; Hauptprogramm
main:

; Stackpointer initialisieren

ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND)
out SPL, temp

; Port B = Ausgang

ldi temp, 0xFF
out DDRB, temp

; Baudrate einstellen

ldi temp, HIGH(UBRR_VAL)
out UBRRH, temp
ldi temp, LOW(UBRR_VAL)
out UBRRL, temp

; Frame-Format: 8 Bit

ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
out UCSRC, temp

sbi UCSRB, RXCIE ; Interrupt bei Empfang
sbi UCSRB, RXEN ; RX (Empfang) aktivieren

sei ; Interrupts global aktivieren

loop:
rjmp loop ; Endlosschleife

; Interruptroutine: wird ausgeführt sobald ein Byte über das UART empfangen wurde

int_rxc:
push temp ; temp auf dem Stack sichern
in temp, sreg ; SREG sichern
push temp

in temp, UDR ; UART Daten lesen
cpi temp, '1' ; empfangenes Byte mit '1' vergleichen
brne int_rxc_1 ; wenn nicht gleich, dann zu int_rxc_1
cbi PORTB, 0 ; LED einschalten, low aktiv
rjmp int_rxc_2 ; Zu int_rxc_2 springen
int_rxc_1:
cpi temp, '0' ; empfangenes Byte mit '0' vergleichen
brne int_rxc_2 ; wenn nicht gleich, dann zu int_rxc_2
sbi PORTB, 0 ; LED ausschalten, low aktiv
int_rxc_2:

pop temp
out sreg, temp ; SREG wiederherstellen
pop temp ; temp wiederherstellen
reti
</syntaxhighlight>

== Handshake ==
Werden Daten schnell über eine serielle Leitung an ein langsames Gerät übertragen, dann kann es passieren, dass die Situation eintritt, dass das empfangende Gerät nicht mehr mitkommt. Das kann z.B. dadurch passieren, dass das empfangende Gerät selbst etwas Zeit für die Bearbeitung der Daten benötigt. Man denke z.B. an die Situation, dass an ein Modem Daten übertragen werden. Das Modem muss diese Daten bearbeiten und unter Umständen über eine langsame Telefonleitung absetzen. Überträgt der AVR seine Daten mit voller Geschwindigkeit an das Modem, so wird auch dem besten Modem irgendwann der interne Speicher ausgehen, in dem es die Daten zwischenspeichern kann.

Was benötigt wird, ist also eine Möglichkeit, wie die Gegenstelle dem Sender signalisieren kann: "Bitte jetzt nichts senden, ich bin beschäftigt!". Die einfachste Form eines derartigen Protokolls, nennt sich Handshake. Es gibt bei RS232 2 Arten, wie dieses Handshake implementiert werden kann: Software-Handshake und Hardware-Handshake.

=== Hardware Handshake ===
Hardware Handshake benutzt die beiden Steuerleitungen RTS - Request to Send und CTS - Clear to Send um die Flusskontrolle durchzuführen.

Die etwas seltsam anmutenden Namen haben historische Ursache. Ursprünglich war RS232 dazu gedacht ein Modem (ein sog. Data Carrier Equipment oder DCE) an einen Endpunkt (DTE oder Data Terminal Equipment) anzuschliessen. Wenn das DTE Daten senden wollte, aktivierte es die Leitung RTS, es fragte praktisch beim DCE an: "Darf ich senden? (engl. Request sending)". Wenn das DCE bereit war, dann aktivierte es seinerseits die CTS Leitung und signalisierte damit "Alles ok. Daten marsch! (engl. Clear to send)". Solange das DCE nicht bereit war, Daten entgegenzunehmen, musste das DTE warten, bis es vom DCE die Freigabe zum Senden bekam.

* Für das DTE gilt: RTS ist ein Ausgang, CTS ist ein Eingang.
* Für das DCE gilt: RTS ist ein Eingang, CTS ist ein Ausgang.

<center>
[[Bild:RS232_orig.png]]
</center>

Das war die ursprüngliche Idee. Heutzutage ist es aber normal, dass 2 DTE miteinander über eine RS232 Verbindung gekoppelt werden. Wird in so einem Fall Hardware Handshake benutzt, so muss jedes DTE seiner Gegenstelle eine korrekte Bedienung der RTS/CTS Leitung vortäuschen.

<center>
[[Bild:RS232_dte.png]]
</center>

Der Teil, dass CTS nur dann bedient wird, wenn über RTS die Anfrage nach der Sendefreigabe erfolgt entfällt dabei. Jeder Gesprächspartner überprüft ganz einfach vor dem Sendevorgang den Zustand der CTS Leitung der Gegenstelle, während der eigene RTS Ausgang zur Signalisierung der Empfangsbereitschaft für die Gegenstelle dient. Dies ist auch der Grund warum bei einem Null-Modem-Kabel nicht nur die RX/TX Leitungen, sondern auch die RTS/CTS Leitungen gekreuzt werden müssen.

Möchte man obige Schaltung um eine Hardware-Flusskontrolle erweitern, so bietet es sich an, die beiden noch freien Kanäle des MAX232 dafür zu verwenden. Die Schaltung sieht dann wie folgt aus:

[[Bild:640px-AVR-RS232_RTS.png|framed|center| UART/MAX232 Beschaltung für RTS/CTS am Beispiel eines Mega16. Achtung: Pinbelegung an den Mega8 anpassen]]

Am Mega8 stehen dann die Signale RTS bzw. CTS an den Pins PD4 bzw. PD5 zur Verfügung. An PD5 kann abgefragt werden, ob die Gegenstelle zum Empfang von Daten bereit ist, während der Mega8 über PD4 signalisieren kann, dass er im Moment keine Daten über die serielle Schnittstelle empfangen kann.

Bedenken sollte man dabei allerdings, dass nach der Rücknahme der Empfangsbereitschaft es je nach Gegenstelle dazu kommen kann, dass noch ein paar Zeichen über die UART eintreffen. Wird zb der Zustand der RTS Leitung vom Füllgrad eines Puffers abhängig gemacht, dann sollte man RTS nicht erst dann abschalten, wenn der Buffer komplett gefüllt ist, sondern schon ein paar Zeichen früher. Ursache könnte zb sein, dass die Gegenstelle über eine Hardware UART verfügt, die einen internen Buffer verfügt. Hat die Gegenstelle erst mal diesen Hardware Buffer gefüllt, dann gibt es oft keine Möglichkeit mehr für das dortige Programm diese UART-Hardware zu stoppen - die Zeichen die in die UART übertragen wurden, werden auf jeden Fall von der Hardware ausgegeben.

=== Software Handshake ===
Software Handshake benutzt die Datenleitung selbst, um die Flußkontrolle von Sender/Empfänger zu erreichen. Dazu wurden im ASCII Code 2 spezielle 'Zeichen' vorgesehen: XON (mit dem Code 0x11) und XOFF (mit dem Code 0x13).

Bemerkt ein Empfänger, dass er in Kürze keine Daten mehr vom Sender aufnehmen kann, dann sendet er seinerseits ein XOFF, woraufhin der Sender das Senden der Daten unterbricht. Ist der Empfänger wieder aufnahmebereit, so gibt er die Übertragung durch das Senden eines XON wieder frei.

Der Nachteil des Software-Handshaking besteht also in mehreren Punkten
* zum einen können nicht mehr alle Datenbytes übertragen werden, da ja die Bytes 0x11 und 0x13 eine spezielle Bedeutung haben. Möchte man Bytes binär übertragen, muss man daher spezielle Vorkehrungen treffen, damit diese Datenbytes nicht durch das Software-Handshaking fehlinterpretiert werden.
* zum anderen muss jeder Sender während er sendet auch gleichzeitig einen möglichen Empfang von Daten überwachen. Die Gegenstelle könnte ja mittels XOFF eine kurzfristige Unterbrechung der Sendung anfordern. Auch muss jeder Sender exakt darüber Buch führen, ob die Leitung zur Zeit im Status XOFF liegt und ob daher Übertragungen überhaupt möglich sind.
* das Senden von XOFF muss rechtzeitig erfolgen. Denn meistens benötigt die Gegenstelle etwas Zeit um das Senden einzustellen. Es kann durchaus sein, dass nach einem XOFF noch ein paar Zeichen von der Gegenstelle eintreffen
* es besteht die Gefahr eines Deadlocks, indem sich beide Seiten gegenseitig mit einem XOFF blockieren, aus dem sie nicht mehr herauskommen.

== Weblinks ==
* [http://www.wormfood.net/avrbaudcalc.php WormFood's AVR Baud Rate Calculator] online.
* [http://www.gjlay.de/helferlein/avr-uart-rechner.html Online Baudraten-Rechner für ATmega AVRs] (JavaScript)

----

{{Navigation_zurückhochvor|
zurücktext=Mehrfachverzweigung|
zurücklink=AVR-Tutorial: Mehrfachverzweigung|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=Speicher|
vorlink=AVR-Tutorial: Speicher}}

[[Category:AVR-Tutorial|UART]]
[[Category:UART und RS232]]

FAQ

2015-08-05T18:46:31Z

Kbuchegg: /* Was hat es mit volatile auf sich */

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

itoa() ist keine C-Standardfunktion (wohl aber ihre Umkehrung atoi() ). Auf manchen Compilern heisst diese Funktion dann folgerichtig _itoa(), wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Library [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

itoa( i, Buffer, 10 ); - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array Buffer groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei printf() (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

Typ ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
c char
d int
f float, double
ld long
u unsigned int
lu unsigned long
p pointer
s string
x ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
X ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

+ Vorzeichen wird immer ausgegeben
- Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
0 anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Wertebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man itoa() nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j 

Das Grundprinzip ist einfach: 
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> 2
8392 / 10 -> 839

839 % 10 -> 9
839 / 10 -> 83

83 % 10 -> 3
83 / 10 -> 8

8 % 10 -> 8
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j 

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit einen Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

Präprozessordefinitionen besitzen keine eigene Datentypen, da sie eine reine Textersetzungen durchführen. Deren Inhalte können aber ggf. zu Werten aufgelöst werden, die datentypbehaftet sind.

=Aktivieren der Floating Point Version von sprintf bei WinAVR bzw AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries'' In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous'' In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File - wie geht das =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen VarExtA bzw. VarExtB, die zu den jewiligen Funktionen A bzw. B gehören. Für dieses System soll eine Aufteilung erfolgen, so dass functionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define A_DEFAULT 5

int functionIntA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define A_DEFAULT 5

int functionA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll. Bei dem Makro A_DEFAULT kann es unterschiedliche Ansichten geben. Handelt es sich um einen Wert, den ein Aufrufer kennen soll, dann wird man das #define ins Header File verschieben (und aus dem C-File rausnehmen). Sieht man dieses #define aber als 'Privatsache' des C-Files, dann bleibt der #define dort wo er jetzt ist.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define A_DEFAULT 5

int functionA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SETTING_B 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur eine Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>
Einfach immer alle Variablen generell volatile zu machen, ist dann auch über das Ziel hinausgeschossen. Denn damit legt man in letzter Konsequenz eine wichtige Möglichkeit für Optimierungen durch den Compiler lahm.

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. CTC Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte TOP). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

AVR-Tutorial: Stack

2015-07-28T12:49:15Z

Kbuchegg: /* Motivation */

== Motivation ==
bisher war es so, dass wenn die Programmausführung an einer anderen Stelle fortgesetzt werden soll, als sich durch die Abfolge der Befehle ergibt, mittels rjmp an diese andere Stelle gesprungen wurde.
Das ist aber oft nicht ausreichend. Oft möchte man den Fall haben, dass man aus der normalen Befehlsreihenfolge heraus eine andere Sequenz von Befehlen ausgeführt wird und wenn diese abgearbeitet ist, genau an die Aufrufstelle zurückgesprungen wird. Da diese eingeschobene Sequenz an vielen Stellen aufrufbar sein soll, gelingt es daher auch nicht, mittels eines rjmp wieder zur aufrufenden Stelle zurück zu kommen, denn dann müsste ja dieser Rücksprung je nachdem von wo der Hinsprung gekommen ist entsprechend modifiziert werden.

Die Lösung dieses Dilemmas besteht in einem eigenen Befehl rcall. Ein rcall macht prinzipiell auch den Sprung zu einem Ziel, legt aber gleichzeitig auch noch die Adresse von wo der Sprung erfolgt ist in einem speziellen Speicherbereich ab, so dass sein 'Gegenspieler', der Befehl ret (wie Return) anhand dieser abgelegten Information wieder genau zu dieser Aufrufstelle zurückspringen kann. Diesen speziellen Speicherbereich nennt man den "[[Stack]]". Stack bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben. Ein Stack (oder Stapel) funktioniert wie ein Stapel Teller. Das Teller, welches zuletzt auf den Stapel gelegt wird, ist auch das erste, welches wieder vom Stapel heruntergenommen wird. Und genau das wird in diesem Fall ja auch benötigt: jeder rcall legt seine Rüclsprungadresse auf den Stack, so dass alle nachfolgenden ret jeweils in umgekehrter Reihenfolge wieder die richtigen Rücksprungadressen anspringen.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
''Dieser Abschnitt ist veraltet, da nahezu alle ATmega/ATtiny Typen IJMP/ICALL unterstützen.''

Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

AVR-Tutorial: Stack

2015-07-28T12:45:20Z

Kbuchegg: /* Motivation */

== Motivation ==
bisher war es so, dass wenn die Programmausführung an einer anderen Stelle fortgesetzt werden soll, als sich durch die Abfolge der Befehle ergibt, mittels '''rjmp''' an diese andere Stelle gesprungen wurde.
Das ist aber oft nicht ausreichend. Oft möchte man den Fall haben, dass man aus der normalen Befehlsreihenfolge heraus eine andere Sequenz von Befehlen ausgeführt wird und wenn diese abgearbeitet ist, genau an die Aufrufstelle zurückgesprungen wird. Da diese eingeschobene Sequenz an vielen Stellen aufrufbar sein soll, gelingt es daher auch nicht, mittels eines '''rjmp''' wieder zur aufrufenden Stelle zurück zu kommen, denn dann müsste ja dieser Rücksprung je nachdem von wo der Hinsprung gekommen ist entsprechend modifiziert werden.

Die Lösung dieses Dilemmas besteht in einem eigenen Befehl, '''rcall'''. Ein '''rcall''' macht prinzipiell auch den Sprung zu einem Ziel, legt aber gleichzeitig auch noch die Adresse von wo der Sprung erfolgt ist in einem speziellen Speicherbereich ab, so dass sein 'Gegenspieler', der Befehl '''ret''' (wie Return) anhand dieser abgelegten Information wieder genau zu dieser Aufrufstelle zurückspringen kann. Diesen speziellen Speicherbereich nennt man den "[[Stack]]". Stack bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben. Ein Stack (oder Stapel) funktioniert wie ein Stapel Teller. Das Teller, welches zuletzt auf den Stapel gelegt wird, ist auch das erste, welches wieder vom Stapel heruntergenommen wird. Und genau das wird in diesem Fall ja auch benötigt: jeder '''rcall'' legt seine Rüclsprungadresse auf den Stack, so dass alle nachfolgenden '''ret''' jeweils in umgekehrter Reihenfolge wieder die richtigen Rücksprungadressen anspringen.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
''Dieser Abschnitt ist veraltet, da nahezu alle ATmega/ATtiny Typen IJMP/ICALL unterstützen.''

Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

AVR-Tutorial: Stack

2015-07-28T12:41:58Z

Kbuchegg:

== Motivation ==
bisher war es so, dass wenn die Programmausführung an einer anderen Stelle fortgesetzt werden soll, als sich durch die Abfolge der Befehle ergibt, mittels RJMP an diese andere Stelle gesprungen wurde.
Das ist aber oft nicht ausreichend. Oft möchte man den Fall haben, dass man aus der normalen Befehlsreihenfolge heraus eine andere Sequenz von Befehlen ausgeführt wird und wenn diese abgearbeitet ist, genau an die Aufrufstelle zurückgesprungen wird. Da diese eingeschobene Sequenz an vielen Stellen aufrufbar sein soll, gelingt es daher auch nicht, mittels eines RJMP wieder zur aufrufenden Stelle zurück zu kommen, denn dann müsste ja dieser Rücksprung je nachdem von wo der Hinsprung gekommen ist, entsprechend modifiziert werden.

Die Lösung dieses Dilemmas besteht in einem eigenen Befehl, RCALL. Ein RCALL macht prinzpiell auch den Sprung zu einem Ziel, legt aber gleichzeitig auch noch die Adresse von wo der Sprung erfolgt ist in einem speziellen Speicherbereich ab, so dass sein 'Gegenspieler', der Befehl RET (wie Return) anhand dieser abgelegten Information wieder genau zu dieser Aufrufstelle zurückspringen kann. Diesen speziellen Speicherbereich nennt man den "[[Stack]]". Stack bedeutet übersetzt soviel wie Stapel. Damit ist ein Speicher nach dem LIFO-Prinzip ("last in first out") gemeint. Das bedeutet, dass das zuletzt auf den Stapel gelegte Element auch zuerst wieder heruntergenommen wird. Es ist nicht möglich, Elemente irgendwo in der Mitte des Stapels herauszuziehen oder hineinzuschieben. Ein Stack (oder Stapel) funktioniert wie ein Stapel Teller. Das Teller, welches zuletzt auf den Stapel gelegt wird, ist auch das erste, welches wieder vom Stapel heruntergenommen wird.

Bei allen aktuellen AVR-Controllern wird der Stack im [[Speicher#RAM|RAM]] angelegt. Der Stack wächst dabei von oben nach unten: Am Anfang wird der Stackpointer (Adresse der aktuellen Stapelposition) auf das Ende des RAMs gesetzt. Wird nun ein Element hinzugefügt, wird dieses an der momentanen Stackpointerposition abgespeichert und der Stackpointer um 1 erniedrigt. Soll ein Element vom Stack heruntergenommen werden, wird zuerst der Stackpointer um 1 erhöht und dann das Byte von der vom Stackpointer angezeigten Position gelesen.

== Aufruf von Unterprogrammen ==
Dem Prozessor dient der Stack hauptsächlich dazu, Rücksprungadressen beim Aufruf von Unterprogrammen zu speichern, damit er später noch weiß, an welche Stelle zurückgekehrt werden muss, wenn das Unterprogramm mit '''ret''' oder die Interruptroutine mit '''reti''' beendet wird.

Das folgende Beispielprogramm (AT90S4433) zeigt, wie der Stack dabei beeinflusst wird:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack.asm Download stack.asm]

<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = r16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch ein paar Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

'''.def temp = r16''' ist eine Assemblerdirektive. Diese sagt dem Assembler, dass er überall, wo er "temp" findet, stattdessen "r16" einsetzen soll. Das ist oft praktisch, damit man nicht mit den Registernamen durcheinander kommt. Eine Übersicht über die Assemblerdirektiven findet man [http://www.avr-asm-tutorial.net/avr_de/beginner/diraus.html hier].

Bei Controllern, die mehr als 256 Byte RAM besitzen (z. B. ATmega8), passt die Adresse nicht mehr in ein Byte. Deswegen gibt es bei diesen Controllern das Stack-Pointer-Register aufgeteilt in '''SPL''' (Low) und '''SPH''' (High), in denen das Low- und das High-Byte der Adresse gespeichert wird. Damit es funktioniert, muss das Programm dann folgendermaßen geändert werden:

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-bigmem.asm Download stack-bigmem.asm]

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

ldi temp, HIGH(RAMEND) ; HIGH-Byte der obersten RAM-Adresse
out SPH, temp
ldi temp, LOW(RAMEND) ; LOW-Byte der obersten RAM-Adresse
out SPL, temp

rcall sub1 ; sub1 aufrufen

loop: rjmp loop

sub1:
; hier könnten ein paar Befehle stehen
rcall sub2 ; sub2 aufrufen
; hier könnten auch Befehle stehen
ret ; wieder zurück

sub2:
; hier stehen normalerweise die Befehle,
; die in sub2 ausgeführt werden sollen
ret ; wieder zurück
</syntaxhighlight>

Natürlich ist es unsinnig, dieses Programm in einen Controller zu programmieren. Stattdessen sollte man es mal mit dem AVR-Studio simulieren, um die Funktion des Stacks zu verstehen.

Als erstes wird mit '''Project/New''' ein neues Projekt erstellt, zu dem man dann mit '''Project/Add File''' eine Datei mit dem oben gezeigten Programm (stack.asm) hinzufügt. Nachdem man unter '''Project/Project Settings''' das '''Object Format for AVR-Studio''' ausgewählt hat, kann man das Programm mit Strg+F7 assemblieren und den Debug-Modus starten.

Danach sollte man im Menu '''View''' die Fenster '''Processor''' und '''Memory''' öffnen und im Memory-Fenster '''Data''' auswählen.

Das Fenster '''Processor'''
* ''Program Counter'': Adresse im Programmspeicher (FLASH), die gerade abgearbeitet wird
* ''Stack Pointer'': Adresse im Datenspeicher (RAM), auf die der Stackpointer gerade zeigt
* ''Cycle Counter'': Anzahl der Taktzyklen seit Beginn der Simulation
* ''Time Elapsed'': Zeit, die seit dem Beginn der Simulation vergangen ist

Im Fenster '''Memory''' wird der Inhalt des RAMs angezeigt.

Sind alle 3 Fenster gut auf einmal sichtbar, kann man anfangen, das Programm (in diesem Fall "stack.asm") mit der Taste F11 langsam Befehl für Befehl zu simulieren.

Wenn der gelbe Pfeil in der Zeile '''out SPL, temp''' vorbeikommt, kann man im Prozessor-Fenster sehen, wie der Stackpointer auf 0xDF (''ATmega8'': 0x45F) gesetzt wird. Wie man im Memory-Fenster sieht, ist das die letzte RAM-Adresse.

Wenn der Pfeil auf dem Befehl '''rcall sub1''' steht, sollte man sich den Program Counter anschauen: Er steht auf 0x02 (''ATmega8'': 0x04).

Drückt man jetzt nochmal auf F11, springt der Pfeil zum Unterprogramm sub1. Im RAM erscheint an der Stelle, auf die der Stackpointer vorher zeigte, die Zahl 0x03 (''ATmega8'': 0x05). Das ist die Adresse im ROM, an der das Hauptprogramm nach dem Abarbeiten des Unterprogramms fortgesetzt wird. Doch warum wurde der Stackpointer um 2 verkleinert? Das liegt daran, dass eine Programmspeicheradresse bis zu 2 Byte breit sein kann, und somit auch 2 Byte auf dem Stack benötigt werden, um die Adresse zu speichern.

Das gleiche passiert beim Aufruf von sub2.

Zur Rückkehr aus dem mit rcall aufgerufenen Unterprogramm gibt es den Befehl '''ret'''. Dieser Befehl sorgt dafür, dass der Stackpointer wieder um 2 erhöht wird und die dabei eingelesene Adresse in den "Program Counter" kopiert wird, so dass das Programm dort fortgesetzt wird.

Apropos Program Counter: Wer sehen will, wie so ein Programm aussieht, wenn es assembliert ist, sollte mal die Datei mit der Endung ".lst" im Projektverzeichnis öffnen. Die Datei sollte ungefähr so aussehen:

http://www.mikrocontroller.net/images/listfile.gif

Im blau umrahmten Bereich steht die Adresse des Befehls im Programmspeicher. Das ist auch die Zahl, die im Program Counter angezeigt wird, und die beim Aufruf eines Unterprogramms auf den Stack gelegt wird. Der grüne Bereich rechts daneben ist der OP-Code des Befehls, so wie er in den Programmspeicher des Controllers programmiert wird, und im roten Kasten stehen die "mnemonics": Das sind die Befehle, die man im Assembler eingibt.
Der nicht eingerahmte Rest besteht aus Assemblerdirektiven, Labels (Sprungmarkierungen) und Kommentaren, die nicht direkt in OP-Code umgewandelt werden.
Der grün eingerahmte Bereich ist das eigentliche Programm, so wie es der µC versteht. Die jeweils erste Zahl im grünen Bereich steht für einen Befehl, den sog. OP-Code (OP = Operation). Die zweite Zahl codiert Argumente für diesen Befehl.

== Sichern von Registern ==
Eine weitere Anwendung des Stacks ist das "Sichern" von Registern. Wenn man z. B. im Hauptprogramm die Register R16, R17 und R18 verwendet, dann ist es i.d.R. erwünscht, dass diese Register durch aufgerufene Unterprogramme nicht beeinflusst werden. Man muss also nun entweder auf die Verwendung dieser Register innerhalb von Unterprogrammen verzichten, oder man sorgt dafür, dass am Ende jedes Unterprogramms der ursprüngliche Zustand der Register wiederhergestellt wird. Wie man sich leicht vorstellen kann ist ein "Stapelspeicher" dafür ideal: Zu Beginn des Unterprogramms legt man die Daten aus den zu sichernden Registern oben auf den Stapel, und am Ende holt man sie wieder (in der umgekehrten Reihenfolge) in die entsprechenden Register zurück. Das Hauptprogramm bekommt also wenn es fortgesetzt wird überhaupt nichts davon mit, dass die Register inzwischen anderweitig verwendet wurden.

[http://www.mikrocontroller.net/sourcecode/tutorial/stack-saveregs.asm Download stack-saveregs.asm]
<syntaxhighlight lang="avrasm">
.include "4433def.inc" ; bzw. 2333def.inc

.def temp = R16

ldi temp, RAMEND ; Stackpointer initialisieren
out SP, temp

ldi temp, 0xFF
out DDRB, temp ; Port B = Ausgang

ldi R17, 0b10101010 ; einen Wert ins Register R17 laden

rcall sub1 ; Unterprogramm "sub1" aufrufen

out PORTB, R17 ; Wert von R17 an den Port B ausgeben

loop: rjmp loop ; Endlosschleife

sub1:
push R17 ; Inhalt von R17 auf dem Stack speichern

; hier kann nach belieben mit R17 gearbeitet werden,
; als Beispiel wird es hier auf 0 gesetzt

ldi R17, 0

pop R17 ; R17 zurückholen
ret ; wieder zurück zum Hauptprogramm
</syntaxhighlight>
Wenn man dieses Programm assembliert und in den Controller lädt, dann wird man feststellen, dass jede zweite LED an Port B leuchtet. Der ursprüngliche Wert von R17 blieb also erhalten, obwohl dazwischen ein Unterprogramm aufgerufen wurde, das R17 geändert hat.

Auch in diesem Fall kann man bei der Simulation des Programms im AVR-Studio die Beeinflussung des Stacks durch die Befehle '''push''' und '''pop''' genau nachvollziehen.

== Sprung zu beliebiger Adresse ==
''Dieser Abschnitt ist veraltet, da nahezu alle ATmega/ATtiny Typen IJMP/ICALL unterstützen.''

Kleinere AVR besitzen keinen Befehl, um direkt zu einer Adresse zu springen, die in einem Registerpaar gespeichert ist. Man kann dies aber mit etwas Stack-Akrobatik erreichen. Dazu einfach zuerst den niederen Teil der Adresse, dann den höheren Teil der Adresse mit '''push''' auf den Stack legen und ein '''ret''' ausführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)

push ZL
push ZH
ret

...
testRoutine:
rjmp testRoutine
</syntaxhighlight>
Auf diese Art und Weise kann man auch Unterprogrammaufrufe durchführen:
<syntaxhighlight lang="avrasm">
ldi ZH, high(testRoutine)
ldi ZL, low(testRoutine)
rcall indirectZCall
...

indirectZCall:
push ZL
push ZH
ret

testRoutine:
...
ret
</syntaxhighlight>

Größere AVR haben dafür die Befehle <code>ijmp</code> und <code>icall</code>.
Bei diesen Befehlen muss das Sprungziel in ZH:ZL stehen.

== Weitere Informationen (von Lothar Müller): ==
* [http://www.mikrocontroller.net/attachment/301/Der-Stack-1.pdf Der Stack - Funktion und Nutzen (pdf)]
* [http://www.mikrocontroller.net/attachment/299/Der-Stack-2.pdf Der Stack - Parameterübergabe an Unterprogramme (pdf)]
* [http://www.mikrocontroller.net/attachment.php/676/Der-Stack-3.pdf Der Stack - Unterprogramme mit variabler Parameteranzahl (pdf) ]

(Der in dieser Abhandlung angegebene Befehl ''MOV ZLow, SPL'' muss ''IN ZL, SPL'' heißen, da SPL und SPH I/O-Register sind. Ggf ist auch SPH zu berücksichtigen --> 2byte Stack-Pointer)

----

{{Navigation_zurückhochvor|
zurücktext=logische Operatoren|
zurücklink=AVR-Tutorial: Logik|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=LCD|
vorlink=AVR-Tutorial: LCD}}

[[Category:AVR-Tutorial|Stack]]

AVR-GCC-Codeoptimierung

2015-07-10T11:02:23Z

Kbuchegg: /* Was */

Entstanden aus diesem [http://www.mikrocontroller.net/topic/66690 Thread] sollen hier ein paar Hinweise/Erfahrungen gegeben werden, um den Quellcode in Punkto Größe und Geschwindigkeit zu optimieren. ''En detail'' ist das Thema komplex, da es stark von der Codeoptimierung des Compilers abhängt. Es ist im Einzelfall ratsam zu prüfen, ob die eigenen Maßnahmen auch erfolgreich waren. Die Diskussionen [http://www.mikrocontroller.net/topic/132624] bzw. [http://www.mikrocontroller.net/topic/180800#new] können als Anhaltspunkte dienen, wie eine solche Prüfung ablaufen kann.

== Prinzipien der Optimierung ==

Wie so oft sollte man nicht einfach wild drauf los optimieren und sich zunächst ein paar Dinge klar machen.

* Warum will ich optimieren?
* Was kann man sinnvoll optimieren?
* Wieviel Rechenzeit oder Speicher soll dabei gespart werden?
* Wie kann optimiert werden?
* "Verfrühte Optimierung ist die Wurzel allen Übels"

Viele Optimierungen sind "Angst-Optimierungen", die nicht wirklich nötig sind. Die Gefahr mit Optimierungen ist, den Code tot zu optimieren, sprich Lesbarkeit, Portierbarkeit und ggf. Fehlerfreiheit sinken massgeblich. Kurz und knapp in diesem [http://blogs.msdn.com/b/audiofool/archive/2007/06/14/the-rules-of-code-optimization.aspx BLOG] formuliert.

=== Warum ===

Optimieren sollte man nur, wenn
* der Speicher nicht mehr ausreicht (RAM, Flash)
* Die Laufzeit für bestimmte Programmteile zu groß wird und somit bestimmte (Echtzeit-)Ausgaben nicht im erforderlichen Zeitrahmen erledigt werden

Weiter sollte man folgende Punkte gegeneinander abwägen:

* Codeverbrauch
* Datenverbrauch. Statisch/Stack/Heap
* Mittlere Laufzeit/maximale Laufzeit
* Entwicklungszeit
* Portabilität (Compiler, Hardware, ...)
* Verständlichkeit der Quelle, siehe [[Strukturierte Programmierung auf Mikrocontrollern]]
* ABI-Konformität

=== Was ===

Die goldene Regel lautet: 90% der Rechenleistung werden in 10% des Codes verbraucht. Diese 10% muss man finden und zum richtigen Zeitpunkt optimieren. Der Rest muss nur sauber und lesbar geschrieben sein. Was jedoch nichts bringt, ist eine Funktion, die von 1 Minute Programmlaufzeit lediglich 1 Sekunde verbraucht, um den Faktor 10 schneller zu machen. Die Programmlaufzeit sinkt dann von 60 Sekunden auf 59.1 Sekunden. Der Aufwand, die Funktion um einen Faktor 10 schneller zu machen ist aber meistens beträchtlich! Kann ich aber den Code, der für die 59 Sekunden verantwortlich ist um lediglich einen Faktor 2 schneller machen (was immer noch oft schwer genug ist, aber auf jeden Fall leichter als ein Faktor 10), dann sinkt die Gesamtlaufzeit von 60 Sekunden auf 30.5 Sekunden. Dort bringt Optimieren augenscheinlich viel mehr!

Um die optimierungswürdigen Stellen zu finden, muss man sein Programm analysieren. Dazu gibt es verschiedene Möglichkeiten.

====Speicherverbrauch nach Funktionen aufschlüsseln====

;map-File:
:dort sind alle globalen und statischen Variablen enthalten. Eine Map-Datei kann mit den GNU-Tools während des Linkens angelegt werden:
::<pre>> avr-gcc ... -Wl,-Map,foo.map</pre>
: Die Option -Wl bewirkt, daß avr-gcc die angehängen Optionen unverändert an den Linker weiterreicht. Dieser erzeugt dann das Mapfile "foo.map", eine Textdatei.
;avr-size: Mit Tools wie avr-size kann die Platzbelegung einzelner Module ermittelt werden:
::<pre>> avr-size -x foo1.o foo2.o ...</pre>
:bzw. die Platzbelegung der elf-Datei:
::<pre>> avr-size foo.elf</pre>
;avr-nm:
::<pre>> avr-nm --size-sort -S foo.elf</pre>
:ergibt eine Liste mit der Größe aller Objekte: der erste Spalte enthälte die Adresse, die zweite Spalte die Größe, die dritte den Typ und die vierte Spalte den zugehörigen Symbolnamen. Der Typ ergibt sich aus der folgenden Zuordnung, wobei Großbuchstaben globale Symbole kennzeichnen und Kleinbuchstaben Symbole, die Modul-lokal sind:
:;T/t: Objekte in der text-Section: Funktionen, Daten im Flash
:;D/d: Objekte im data-Segment (initialisierte Daten)
:;B/b: Objekte im bss-Segment (Null-initialisierte Daten)

;avr-gcc: Der Compiler hat bereits Informationen über die übersetzten Funktionen, die man direkt zur Analyse verwenden kann. Dazu lässt man avr-gcc die Assembler-Ausgabe, die ohne weiteres Zutun nur als temporäre Datei angelegt wird, abspeichern. Etwa für die Quelldatei foo.c:
::<pre>> avr-gcc -save-temps foo.c -c ...</pre>
:Die Assembler-Datei wird damit als foo.s angelegt und nicht gelöscht. (Das ebenfalls angelegte Präcompilat foo.i wird nicht benötigt). Für jede Funktion gibt avr-gcc 3.4.x im Prolog einen Kommentar der Form<ref>Für avr-gcc 4.x sehen die Kommentare anders aus oder fehlen je nach Compilerversion ganz</ref>
::<pre>/* prologue: frame size=0 */</pre>
:aus, was die Größe des aktuellen Frames angibt. Dies ist der Platz auf dem Stack, der für lokale Variablen benötigt wird. Am besten ist es, wenn die Frame-Size wie im Beispiel gleich 0 ist. Ansonsten sollte man versuchen, diese Größe auf Null zu bringen. Für Variablen, die nicht in Registern gehalten werden können, müssen Speicherzugriffe in den Stack erzeugt werden. Diese machen das Programm sowohl größer aus auch langsamer. Zudem reserviert avr-gcc bei solche Funktionen das Y-Register als Frame-Pointer; das Y-Register steht damit nicht mehr für lokale Variablen zur Verfügung was sich ebenfalls ungünstig auf die Codegüte auswirkt. Ein Grund für das Anlegen eines Frames können zu viele lokale Variablen sein (zB lokale Puffer/Arrays) oder lokale Variablen/Strukturen/Parameter mit ungünstigen Größen, etwa eine 3-Byte große Struktur.

: Neben dieser Information gibt avr-gcc Kommentare der Gestalt
::<pre>/* prologue end (size=2) */</pre>
:aus die darüber informieren, wie viele Register auf dem Stack gesichert wurden.

: Zusammen mit Werkzeugen wie grep, die in jedem Linux und jeder WinAVR-Distribution enthalten sind, findet man schnell Übeltäter wie Funktionen mit Frame.

;Assembler-Code sichten: Ein kurzer Blick auf den erzeugten Assembler-Code zeigt oft, wie gut der Compiler den Code umgesetzt hat. Den erzeugten Assembler-Code zu überfliegen ist wesentlich zeitsparender als selbst in Assembler zu programmieren. Je nach Gusto verwendet man zur Einsicht den Assembler-Code, den avr-gcc ausgibt (s.o.), Assembler-Dumps des Assemblers, List-Files oder HEX-Dumps. Siehe auch<ref>[http://rn-wissen.de/index.php/Assembler-Dump_erstellen_mit_avr-gcc roboternetz.de: Assembler-Dump erstellen mit avr-gcc]</ref>

;Hilfsmittel: einkaufen oder selber bauen. Es gilt herauszufinden, welche Funktion massig Stack durch lokale Variablen verbraucht. Stacktracer können das. Wenn man keinen hat, dann muss man sich eben selber einen bauen, indem man den Stackpointer mitloggt. Zur Not einen Code-Review machen: Alle Funktionen optisch durchgehen und die identifizieren, die viele Variablen anlegen. Dann die Aufrufhierarchie der Funktion feststellen: Wirken sich die vielen Variablen überhaupt aus oder entsteht mein Problem durch eine tiefe Funktionsaufrufhierarchie, bei der zwar wenige Variablen pro Funktion im Spiel sind, aber die Menge der ineinandergeschachtelten Aufrufe 'das Kraut fett macht'
;Profitools: können das alles fast auf Knopfdruck, kosten aber viel Geld

====Laufzeit messen====

*Simulator
*In Echtzeit mittels Testpin, welche an Anfang einer Funktion/Blocks gesetzt wird und am Ende wieder gelöscht wird. Mit einem [[Oszilloskop]] kann man so sehr einfach die Laufzeit messen.

; Anmerkung: Solche Messverfahren liefern immer nur eine ''untere'' Schranke für die Laufzeit, niemals eine obere Schranke. Eine obere Schranke, wie man sie etwa in sicherheitsktitischen Systemen benötigt, liefert eine statische Codeanalyse.

=== Wieviel ===

Der Aufwand von Optimierungen wächst exponentiell. Die letzten paar Prozent brauchen überproportional viel Aufwand.

=== Wie ===

Meist muss man die Wahl treffen ob man Speicher oder Rechenzeit sparen will, beides gleichzeitg geht meist nicht. Das Konzept heißt 'Space for Time' und kann in beide Richtungen verwendet werden. Als Beispiel soll eine komplizierte Berechnung dienen. Diese kann man relativ kompakt in eine Funktion packen, welche dann aber eher langsam ist. Oder man benutzt eine sehr große Tabelle, in welcher die Ergebnisse schon für jeden Eingangswert vorausberechnet wurden. Diese Lösung ist sehr schnell, verbraucht aber sehr viel Speicher.

* Inlining von Funktionen erhöht den Speicherverbrauch, senkt aber die Laufzeit. Beispiel: Funktion A ist 50 Byte groß und wird 10 mal im Programm aufgerufen. Ein Aufruf kostet 10 Byte:
** Ohne Inline: 10 * 10Byte + 50 Byte = 150 Byte Platzverbrauch
** Mit Inline: 10 * 50 Byte = 500 Byte
* Optimierer einschalten
* möglichst keine Floating Point Operationen, besser ist meist [[Festkommaarithmetik]]
* Formeln umstellen und zusammenfassen
* Variablen so klein wie möglich, uint8_t wo's nur geht.
* Wirklich zeitkritische Funktionen und Interrupts als Assemblercode in separater Datei

== GCC-Optionen ==

=== Optimierungs-Level ===

avr-gcc kennt mehrere Optimierungsstufen:
;<tt>-O0</tt>: Keine Optimierung des erzeugten Codes. Diese Optimierungsstufe optimiert den Resourcenverbrauch des ''Hostrechners'' und die Nachvollziehbarkeit der erzeugten Codes anhand von Debug-Information. Alle lokalen Variablen werden auf dem Stack angelegt und nicht in Registern gehalten. Es werden keine komplexen Optimierungsalgorithmen angewandt; lediglich Konstanten wie 1+2 werden zu 3 gefaltet.

;<tt>-O1</tt>: Je höher die Optimierungsstufe, desto schwieriger ist der erzeugte Code nachvollziehbar — auch mit Debugger. Diese O-Stufe ist ein Kompromiss zwischen aggressiver Optimierung und Nachvollziehbarkeit des erzeugten Codes. Ein ehernes Gesetz in GCC ist, dass er den gleichen Code erzeugen muss unabhängig davon, ob Debug-Information erzeugt wird oder nicht. Im Umkehrschluss erlaubt volle Debug-Unterstützung nicht alle Optimierungen, wozu diese Optimierungsstufe dient.

;<tt>-O2</tt>: Optimierung auf Geschwindigkeit. Für AVR nur mässig sinnvoll, da sich der Codezuwachs nicht in einen entsprechenden Geschwindigkeitszuwachs transformiert. Dies liegt vor allem daran, daß Sprünge und Funktionsaufrufe auf AVR im Vergleich zu anderen Architekturen sehr billig sind. Es bringt also kaum einen Geschwindigkeitszuwachs, einen Block zu kopieren um einen Sprung zu sparen. Hingegen vergrößert dies den Code deutlich.

;<tt>-O3</tt>: Dito. Auf Teufel-komm-raus Funktionen zu inlinen, Schleifen aufzurollen oder gar Funktionen mehrfach für unterschiedliche Aufruf-Szenarien zu implementieren, ist auf einem kleinen µC wie AVR der Overkill.

;<tt>-Os</tt>: Optimierung auf Codegröße. Die bevorzugte Optimierungsstufe für AVR und viele andere µC.

Jede O-Option ist ein Sammlung von verschiedenen Schaltern, welche bestimmte Optimierungsstrategien aktivieren. Um zu sehen, welche Schalter dies genau sind, erzeugt man wie oben beschrieben mit den Schalten
-save-temps -fverbose-asm
die Assembler-Ausgabe von gcc und schaut die Optionen im s-File nach. Einzelne Optionen lassen sich gezielt aktivieren bzw. deaktivieren und damit zum Beispiel zum <tt>-Os</tt>-Paket hinzufügen.

Eine Ausnahme bildet <tt>-O0</tt>: Hier ist Code-Optimierung generell deaktiviert, und Optimierungsschalter bleiben ohne Wirkung.

=== Feinabstimmung der Optimizer ===

Kandidaten für Optimierungsoptionen sind folgende Schalter. <tt>-m</tt> kennzeichnet maschinenspezifische Schalter, die nur für AVR gültig sind. <tt>-f</tt> bzw. <tt>-fno-</tt> sind maschinenunabhängige Schalter, die auch für andere Architekturen verfügbar sind.

;<tt>-fno-split-wide-types</tt>: Je nach Quelle kann die Deaktivierung von <tt>-fsplit-wide-types</tt> besseren Code ergeben.

;<tt>-fno-inline-small-functions</tt>: Relativ kleine Funktionen /immer/ zu inlinen kann den Code unnötig vergrößern, dieser Schalter unterbindet das automatische Inlinen kleiner Funktionen.

;<tt>-finline-limit=</tt>''wert'': Maximalwert für automatisch geinlinte Funktionen. In einschlägigen Foren werden kleine Werte für ''wert'' vorgeschlagen, z.B. 1…3

;<tt>-mcall-prologues</tt>: Die für aufwändige Funktionen mitunter recht langen push/pop-Sequenzen werden durch Hilfsfunktionen ersetzt. Das kann vor allem bei grossen Programmen Platz sparen. Die Ausführungszeit steigt an.

;<tt>-fno-jump-tables</tt>: Switch-Statements werden hierdurch mitunter deutlich kürzer.

;<tt>-fno-move-loop-invariants -fno-tree-loop-optimize</tt>: Einige Schleifenoptimierungen, welche die Registerlast erhöhen und für AVR kaum zu einem Geschwindigkeitszuwachs führen, werden deaktiviert.

;<tt>-fno-tree-switch-conversion</tt>: Neue GCC-Versionen können switch/case Anweisungen u.U. in Lookup-Tabellen umwandeln, die im RAM abgelegt werden, siehe auch [http://gcc.gnu.org/PR49857 PR49857]. Dieser Optimierung ist bei RAM-Knappheit in Betracht zu ziehen, bring aber natürlich nur dann etwas, wenn diese Optimierung auch ausgeführt wurde.

;<tt>-fno-optimize-sibling-calls</tt>: Ab 4.7 wirksam: Tailcall-Optimierung kann den Code vergrößern, wenn Epiloge mehrfach erzeugt werden. In diesem Fall deaktiviert man die Tailcall-Optimierung.

;<tt>-maccumulate-args</tt>: Ab 4.7: Funktionen, die mehrere printf-artige Aufrufe enthalten und viele Artumente per Stack an diese übergeben, werden u.U kleiner.

;<tt>-mstrict-X</tt>: Ab 4.7: Beeinflusst die Art und Weise, wie das X-Register zur Adressierung verwendet wird.

;<tt>-mbranch-cost=</tt>''wert'': Ab 4.7: Setzt die Kosten, mit der der Compiler einen bedingten Sprunge veranschlagt. Default-Wert ist ''wert''<tt>=0</tt>.

;<tt>-fno-caller-saves</tt>: Kann zu effizienteren Pro-/Epilogen beitragen.

;<tt>-fno-tree-ter</tt>: Es gibt Fälle, in denen der Compiler die Berechnung temporärer Variablen über volatile-Zugriffe und Memory-Barriers zieht, siehe [http://gcc.gnu.org/PR53033 PR53033]. Von der C-Spezifikation her ist dies zulässig, kann aber zu unerwünschter Umsortierung der volatile-Operation führe, z.B. wenn es sich dabei um eine <tt>SEI</tt>-Instruktion handelt. Ohne diese Optimierung wird der Code evtl. etwas größer, aber Probleme wie im PR beschrieben können vermieden werden.

;<tt>--param case-values-threshold=</tt>''wert'': Ab 4.7: Schwellwert an Einträgen in einem switch/case, ab dem anstatt eines binären if/else-Entscheidungsbaums eine Sprungtabelle zu den case-Labels erzeugt wird. Voreinstellung ab 4.7 ist ''wert''<tt>=7</tt>. Ältere Compilerversionen verwenden andere Werte. Siehe auch <tt>-f[no-]jump-tables</tt>.

Generell gilt für all diese Optionen, daß sie abhängig vom Projekt zu einer Codeverbesserung oder -verschlechterung führen können — dies ist i.d.R. vom Projektcode abhängig.

=== Linker-Optionen ===

;<tt>-ffunction-sections -Wl,--gc-sections</tt>: Der Linker wirft nicht referenzierte Sections weg, was die Codegröße günstig beeinflussen kann. Diese Optimierung verkleinert den Code nur dann, wenn nicht verwendete Funktionen in der Anwendung rumgammeln. Weil der Linker nur auf Section-Ebene optimieren kann, muss zusätzlich der Compiler mit <tt>-ffunction-sections</tt> aufgerufen werden, um die Anwendung auf möglichst viele Sections zu verteilen.

;<tt>-Wl,--relax -mrelax</tt>: Der Linker fasst Tail-Calls wie
::<tt>CALL some_function RET</tt>
: zusammen als
::<tt>JMP some_function</tt>
: Siehe auch die Compiler-Option <tt>-f[no-]optimize-sibling-calls</tt> von oben. Zudem wird <tt>CALL</tt> umgewandelt zur kürzeren <tt>RCALL</tt>-Instruktion falls das Sprungziel im ±4 KiB-Zielbereich von <tt>RCALL</tt> liegt. Analog für <tt>JMP</tt> zu <tt>RJMP</tt>.

: Die beiden Optionen sind gleichwertig; die erste Variante veranlasst den Compiler, den Linker mit <tt>--relax</tt> aufzurufen. Die zweite Variante verwendet den allgemeinen <tt>-Wl</tt>-Mechanismus, um eine Option von der Compiler-Kommandozeile an den Linker durchzureichen.

=== Weitere Optionen ===

;<tt>-mtiny-stack</tt>: Der Compiler ändert nur das Low-Byte des Stackpointers (SP), was auf Controllern mit 16-Bit SP zu kleinerem Code führen kann. Benötigt der Code Platz auf dem Stack, so erzeugt der Compiler u.U. Code, der den SP liest, einen Offset aufaddiert/abzieht und den SP dann zurückschreibt. Dies ist aufwändig. Für den Fall, daß sich dabei das High-Byte SP nicht ändert, kann Code eingespart werden.

:Beispiel: ATtiny44 hat RAM von <tt>0x60</tt> bis <tt>0x15f</tt>. Braucht die Anwendung nicht mehr als <tt>0x60</tt> = 96 Bytes an Stack, dann kann mit <tt>-mtiny-stack</tt> compiliert werden.

=== Änderung des Binärinterfaces per Option ===

{{Warnung|
;Warnung: Im Gegensatz zu den Optionen der vorherigen Abschnitte, bei denen es sich um reine Optimierungsoptionen handelt, ändern die folgenden Optionen das Binärinterface (ABI) des vom Compiler erzeugten Codes und sind daher nur nach eingehender Prüfung anzuwenden! Wird eine Anwendung mit diesen Schaltern übersetzt, dann ist sicher zu stellen, daß ''alle'' Module inclusive Libraries damit derzeugt werden oder die ABI-Änderung sich nicht auf Code in Bibliotheken auswirkt!
}}

Vorsicht in auch deshalb geboten, weil manche Entwicklungsumgebungen wie "Atmel Studio" das ABI ''per Default'' verändern und ohne daß der Anwender es extra anfordert.

;<tt>-funsigned-char</tt>: Anders als im avr-gcc ABI ist der Typ <tt>char</tt> unsigned anstatt signed.
:Besser: Verwende die C99-Typen wie <tt>uint8_t</tt> aus dem C99-Header <tt>stdint.h</tt>.

;<tt>-funsigned-bitfields</tt>: Bitfelder mit Basetype <tt>char</tt>, <tt>short</tt>, <tt>int</tt> <tt>long</tt> und <tt>long long</tt> werden als unsigned implementiert anstatt als signed wie in der avr-gcc ABI.
:Besser: Wenn ein Bitfeld unsigned sein soll, dann mach es unsigned!

;<tt>-fpack-struct</tt>: Im Gegensatz zur avr-gcc ABI werden Strukturen und Unions per default gepackt.
:Besser: Wenn ein zusammengesetzter Typ gepackt werden soll, mache ein Typedef mit explizitem <tt>__attribute__((packed))</tt>!

;<tt>-fshort-enums</tt>: Enum-Typen werden so kurz wie möglich implementiert anstatt als <tt>int</tt> gemäß avr-gcc ABI.

;<tt>-mint8</tt>: Ein <tt>int</tt> ist nur nocht 8 Bits breit. Dies entspricht nicht mehr dem C-Standard und wird nicht durch die C-Bibliotheken wie AVR-Libc oder newlib unterstützt! Die Codegröße von 8-Bit Operationen kann sich verkleinern, weil andere Integer-Promotion Regeln angewandt werden. Literals müssen ggf. angepasst bzw gecastet werden, siehe auch C99-Makros wie <tt>UINT16_C</tt> aus <tt>stdint.h</tt>.

== Anpassungen der Quelle ==

=== Attribute noreturn, OS_main und OS_task ===

Mikrocontroller-Programme laufen normalerweise in einer Endlosschleife, so dass die main-Routine nie verlassen wird.
Teilt man dies dem Compiler mit, kann er bestimmte Optimierungen durchführen.
So ist es zum Beispiel unnötig, Code zum Sichern und Zurücklesen von Registern zu erzeugen.

Das Mitteilen funktioniert beim gcc über Attribute, die man der Deklaration oder bei der Implementierung einer Funktion anhängt:
<syntaxhighlight lang="c">static void main_loop (void) __attribute__((noreturn));
void main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</syntaxhighlight>
oder
<syntaxhighlight lang="c">static void __attribute__((noreturn))
main_loop (void)
{
while (1)
{
// Hauptschleife
}
}</syntaxhighlight>

Die Funktion <tt>main_loop</tt> kann dann in <tt>main</tt> aufgerufen werden:

<syntaxhighlight lang="c">int main (void)
{
main_loop();

return 0;
}</syntaxhighlight>
Das abschließende <tt>return</tt> wird vom Compiler wegoptimiert und belegt keinen Speicher.

<tt>avr-gcc</tt> kennt weiterhin die Attribute <tt>OS_main</tt> und <tt>OS_task</tt>.
Die Verwendung von <tt>OS_main</tt> kann etwa aussehen wie folgt. Natürlich kann auch wie oben die Hauptschleife in einer eigenen Funktion implementiert werden, und das <tt>return</tt> verursacht keinen zusätzlichen Code:
<syntaxhighlight lang="c">int __attribute__((OS_main))
main (void)
{
while (1)
{
// Hauptschleife
}

return 0;
}</syntaxhighlight>

=== Statische Variablen in einer Struktur sammeln ===

Gibt es in einem Programm mehrere inhaltlich zusammengehörende Variablen, dann ist es sinnvoll diese in einer Struktur zu vereinigen. Neben einer klareren Programm- bzw. Datenstruktur kann dies auch zu kleinerem Code führen.

Beispiel ist die folgende kleine Routine, welche die Zeit in der globalen <tt>time</tt>-Strukture um eine Sekunde erhöht:

<syntaxhighlight lang="c">
#include <stdint.h>

typedef struct
{
uint8_t second;
uint8_t minute;
uint8_t hour;
} time_t;

// Globale time-Struktur enthält die Zeit
time_t time;

void next_second (void)
{
// Zeiger auf die globale time-Struktur
time_t *ptime = &time;

// time um 1 Sekunde erhöhen

if (++ptime->second == 60)
{
ptime->second = 0;

if (++ptime->minute == 60)
{
ptime->minute = 0;

if (++ptime->hour == 24)
ptime->hour = 0;
}
}
}
</syntaxhighlight>

Die Funktion enthält mehrere indirekte Zugriffe auf die <tt>time</tt>-Struktur, und es wäre günstig, wenn <tt>avr-gcc</tt> indirekte Adressierung für die Zugriffe verwendet: Alle Zugriffe geschehen über den Struktur-Zeiger <tt>ptime</tt>, und ein indirekter Zugriff per <tt>LD</tt>, <tt>LDD</tt>, <tt>ST</tt> oder <tt>STT</tt> kostet 2 Bytes, während die direkten Spreicherzugriffe <tt>LDS</tt> und <tt>STS</tt> jeweils 4 Bytes verbrauchen.

<tt>avr-gcc</tt> erzeugt mit Optimierung auf Größe jedoch folgenden Code:

<syntaxhighlight lang="c">
next_second:
// if (++ptime->second == 60)
lds r24, time
subi r24, -1
sts time, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
sts time, __zero_reg__
// if (++ptime->minute == 60)
lds r24, time+1
subi r24, -1
sts time+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
sts time+1, __zero_reg__
// if (++ptime->hour == 24)
lds r24,time+2
subi r24, -1
sts time+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
sts time+2, __zero_reg__
.L1:
ret
</syntaxhighlight>
D.h. obwohl der C-Code indirekt zugreift, enthält das Compilat direkte Zugriffe und der Code belegt 56 Bytes an Flash. Grund ist, daß der Compiler den Inhalt der Variablen <tt>ptime</tt> kennt und daher die indirekten Struktur-Zugriffe in direkte umwandelt.

Um indirekte Adressierung im erzeugten Code zu erzwingen, kann man die Struktur-Adresse als Parameter übergeben:
<syntaxhighlight lang="c">
void next_second (time_t *ptime)
</syntaxhighlight>
oder – als hässliche Lösung – dem Compiler des Wissen um den Inhalt von <tt>ptime</tt> per Inline-Assembler nehmen:
<syntaxhighlight lang="c">
asm ("" : "+r" (ptime));
</syntaxhighlight>

Dies führt denn zu folgendem Code, der um 25% kleiner ist und nur noch 42 Bytes Flash belegt:
<syntaxhighlight lang="c">
next_second:
// time_t *ptime = &time;
// asm ("" : "+r" (ptime));
ldi r30, lo8(time)
ldi r31, hi8(time)
// if (++ptime->second == 60)
ld r24, Z
subi r24, -1
st Z, r24
cpi r24, 60
brne .L1
// ptime->second = 0;
st Z, __zero_reg__
// if (++ptime->minute == 60)
ldd r24, Z+1
subi r24, -1
std Z+1, r24
cpi r24, 60
brne .L1
// ptime->minute = 0;
std Z+1, __zero_reg__
// if (++ptime->hour == 24)
ldd r24, Z+2
subi r24, -1
std Z+2, r24
cpi r24, 24
brne .L1
// ptime->hour = 0;
std Z+2, __zero_reg__
.L1:
ret
</syntaxhighlight>

Weil AVRs nur zwei Zeiger-Register haben, die über diese Addressierungsart verfügen (Y und Z), ist diese Optimierung nur eingeschränkt anwendbar.

Werden etwa Z oder Y für andere Zwecke benötigt – etwa für Flash-Adressierung per <tt>LPM</tt> oder Y als Frame-Pointer gebraucht – verkleinert sich das Anwendungsfeld noch weiter. Zudem müssen genügend Struktur-Zugriffe nacheinander erfolgen, damit ein positiven Effekt auf die Codegröße zustande kommt. Immerhin muss die Adresse geladen werden, das Zeiger-Register wird belegt und steht nicht für andere Variablen zur Verfügung, und im Falle von Y kommen <tt>PUSH</tt>/<tt>POP</tt> im Prolog/Epilog hinzu. Werden viele unterschiedliche Struktur-Pointer verwendet ("viele" relativ zur Anzahl der verfügbaren Pointer-Registern), kann die Codegröße auch ansteigen.

Direkte Zugriffe sind in jedem Falle schneller, denn direkte und indirekte Zugriffe kosten die gleiche Zeit. Die Indirekten Zugriffe erfordern jedoch die Initialisierung des Zeiger-Registers und evl <tt>PUSH</tt>/<tt>POP</tt>.

=== Multiplikationen mit Konstanten ===

Der Compiler instanziiert sofort eine teure allgemeine Bibliotheksfunktion, auch wenn es anders ginge. Ich hatte eine einzige 32-bit Multiplikation mit 10 drin, die mir ein mulsi3 beschert hat. Mit a = (b<<3) + (b<<1) geht es in dem Fall kürzer. Wie gesagt, map-File beobachten.

;Anmerkung: Variablen als unsigned definieren, dann sollte der Compiler das selbst machen.

;Anmerkung: Auch Schieben ist teuer auf AVR. Schauen wir uns also mal an, was aus folgendem Code wird:

<syntaxhighlight lang="c">
uint32_t foo (uint32_t i)
{
return i*10;
}

uint32_t bar (uint32_t i)
{
return (i << 1) + (i << 3);
}
</syntaxhighlight>

{{Scrollbox|15ex;|
<pre>
00000032 <foo>:
32: 2a e0 ldi r18, 0x0A ; 10
34: 30 e0 ldi r19, 0x00 ; 0
36: 40 e0 ldi r20, 0x00 ; 0
38: 50 e0 ldi r21, 0x00 ; 0
3a: 19 d0 rcall .+50 ; 0x6e <__mulsi3>
3c: 08 95 ret

0000003e <bar>:
3e: 26 2f mov r18, r22
40: 37 2f mov r19, r23
42: 48 2f mov r20, r24
44: 59 2f mov r21, r25
46: 22 0f add r18, r18
48: 33 1f adc r19, r19
4a: 44 1f adc r20, r20
4c: 55 1f adc r21, r21
4e: e3 e0 ldi r30, 0x03 ; 3
50: 66 0f add r22, r22
52: 77 1f adc r23, r23
54: 88 1f adc r24, r24
56: 99 1f adc r25, r25
58: ea 95 dec r30
5a: d1 f7 brne .-12 ; 0x50 <__SREG__+0x11>
5c: 26 0f add r18, r22
5e: 37 1f adc r19, r23
60: 48 1f adc r20, r24
62: 59 1f adc r21, r25
64: 95 2f mov r25, r21
66: 84 2f mov r24, r20
68: 73 2f mov r23, r19
6a: 62 2f mov r22, r18
6c: 08 95 ret

0000006e <__mulsi3>:
6e: ff 27 eor r31, r31
70: ee 27 eor r30, r30
72: bb 27 eor r27, r27
74: aa 27 eor r26, r26

00000076 <__mulsi3_loop>:
76: 60 ff sbrs r22, 0
78: 04 c0 rjmp .+8 ; 0x82 <__mulsi3_skip1>
7a: a2 0f add r26, r18
7c: b3 1f adc r27, r19
7e: e4 1f adc r30, r20
80: f5 1f adc r31, r21

00000082 <__mulsi3_skip1>:
82: 22 0f add r18, r18
84: 33 1f adc r19, r19
86: 44 1f adc r20, r20
88: 55 1f adc r21, r21
8a: 96 95 lsr r25
8c: 87 95 ror r24
8e: 77 95 ror r23
90: 67 95 ror r22
92: 89 f7 brne .-30 ; 0x76 <__mulsi3_loop>
94: 00 97 sbiw r24, 0x00 ; 0
96: 76 07 cpc r23, r22
98: 71 f7 brne .-36 ; 0x76 <__mulsi3_loop>

0000009a <__mulsi3_exit>:
9a: 9f 2f mov r25, r31
9c: 8e 2f mov r24, r30
9e: 7b 2f mov r23, r27
a0: 6a 2f mov r22, r26
a2: 08 95 ret

</pre>
}}

: Der Funktionsaufruf samt Lib-Funktion ist garnicht sooo teuer. Bereits mit zwei Multiplikationen im Programm — auch einer Multiplikation mit einer anderen Konstanten oder einer Variablen — gewinnt die lib-Version, da der Code wiederverwendet wird. Übrigens sind diese Multiplikationsroutinen und auch die in die libgcc enthaltenen Divisionen keine "normalen" Funktionen wie sie von C erzeugt werden. avr-gcc weiß genau, welche Register diese Routinen belegen und welche nicht. Damit ist der Aufruf einer solchen Funktion billiger als ein herkömmlicher Funktionsaufruf, bei dem die Funktion als Blackbox behandelt werden muss, die alle call-clobbered Register zerstört.

=== Alle Variablen nur so breit wie nötig ===

Hatte ich eigentlich schon, nur an einigen wenigen Stellen war ich da etwas nachlässig. Mitunter reicht ein kleinerer Typ doch, wenn man z. B. vorher geeignet skaliert. Am besten nur die skalaren Typen aus <stdint.h> verwenden, das erleichtert auch das Folgende. Bei RAM Knappheit: kann ich Strings sinnvollerweise aus dem RAM ins Flash verbannen? Kann ich es mir leisten mehrere Flag-Variablen in ein Byte zusammenzufassen, auch wenn dann die Zugriffe möglicherweise etwas langsamer werden.

=== Logische Operatoren werden auf int-Größe erweitert ===

Obwohl der AVR ein 8-Bit Controller ist, verlangt der C-Standard, daß ein <tt>int</tt> mindestens 16 Bits groß ist. Wegen den Promotion-Regeln von C werden 8-Bit Operanden in Operationen auf 16 Bits aufgeweitet. Beispiel:

<syntaxhighlight lang="c">
#include <stdint.h>

uint8_t c;

void foo (uint8_t a, uint8_t b)
{
if (a == ~b)
c = 0;
}
</syntaxhighlight>
Den zweiten Operanden mit dem Komplement weitet der Compiler auf 16 Bit auf, wodurch alle high-Bits von <tt>~b</tt> gesetzt werden. Der Compiler erkennt, daß der Vergleich niemals wahr ist und optimiert ihn weg:
<syntaxhighlight lang="c">
foo:
ret
</syntaxhighlight>

Ein Cast verhindert dieses:
<syntaxhighlight lang="c">
void foo (uint8_t a, uint8_t b)
{
if (a == (uint8_t) ~b)
c = 0;
}
</syntaxhighlight>
was übersetzt wird zu:
<syntaxhighlight lang="c">
foo:
// if (a == (uint8_t) ~b)
com r22
cpse r24, r22
rjmp .L1
// c = 0
sts c, __zero_reg__
.L1:
ret

</syntaxhighlight>

;Achtung: Tatsächlich handelt es sich dabei nicht um ein Optimierungsproblem, sondern einen typischen Programmierfehler. Die beiden Varianten sind keineswegs identisch! Bei Variablen vom Typ <tt>uint8_t</tt> ist der Ausdruck <tt>(a == ~b)</tt> immer falsch! Dies unterstreicht mehr als eindringlich, daß eine gute Kenntnis der Programmiersprache das A und O jedes erfolgreichen Programmierers ist. Kenne zuallerst mal deine Programmiersprache - und zwar auch in den intimen Details!

=== Speichern von globalen Flags ===

Oft werden in den Programmen Flags verwendet um beispielsweise eingetroffene Interrupts in der main-Routine auszuwerten. Hierzu wird üblicherweise eine globale Variable verwendet.

Um den Wert dieser Variable abzufragen, muss sie jedoch erst aus dem SRAM in ein Register geladen werden, und kann dann erst auf ihren Status hin überprüft werden. Eine Möglichkeit ist, der globalen Variablen ein einziges Register fest zuzuordnen:
<syntaxhighlight lang="c">
register uint8_t counter8_1 asm("r2");
register uint8_t counter8_2 asm("r3");
register uint16_t counter16_1 asm("r4"); // r4:r5
register uint16_t counter16_2 asm("r6"); // r6:r7
</syntaxhighlight>
siehe auch: http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_regbind

Als Alternative kann man ein nicht verwendetes Register des I/O-Bereichs verwenden. Dabei würde sich z. B. das Register eines zweiten UARTs, oder das EEPROM-Register anbieten, falls diese nicht benötigt werden.

Neuere AVR-Modelle besitzen für diesen Zweck 3 frei verwendbare Bytes im bitadressierbaren I/O-Bereich: GPIOR0-2.

{{Warnung|
;Warnung: Dieses Vorgehen verändert das ABI! Um dieses Feature fehlerfrei anzuwenden, ist einiges an Wissen über die Interna von GCC notwendig. Auch ein korrekt funktionierendes Programm ist keine Garantie dafür, daß die globalen Register fehlerfrei implementiert wurden. Unter Umständen bringen erst spätere Codeänderungen/-erweiterung den Fehler zum Vorschein, und weil der Fehler vorher nicht akut war, sucht man sich den Wolf an der falschen Stelle im Code anstatt bei der globalen Registern. Siehe auch [[Globale Register]].}}

=== Puffern von volatile-Variablen ===

Der Compiler behandelt volatile-Variablen bei mehreren Manipulationen wie heiße Kartoffeln. Für jeden einzelnen Vorgang wiederholt sich das Spiel:

* aus dem Speicher holen
* bearbeiten
* zurückspeichern

Unter Umständen ist dieses Verhalten unsinnig. Ein Minimalbeispiel:

<syntaxhighlight lang="c">
volatile char var;

ISR()
{
var++;

if (var > 100)
var = 0;
}

void main (void)
{
while (1)
printf (var);
}
</syntaxhighlight>

Hier wird '''var''' pro [[ISR]]-Ausführung zwei mal aus dem RAM geholt und zurückgeschrieben. Das ist überflüssig, weil die Interruptrountine nicht unterbrochen werden kann. Aus Sicht der ISR bräuchte man eigentlich kein volatile, kann es aber wegen des Zugriffs aus main heraus nicht weglassen. Eine Lösung findet sich im folgenden Schnipsel:

<syntaxhighlight lang="c">
volatile char var;

ISR()
{
char temp = var;

if (++temp > 100)
temp=0;

var = temp;
}

void main (void)
{
while (1)
printf (var);
}
</syntaxhighlight>

Hier wird die globale Variable '''var''' in der lokalen Variable '''temp''' gepuffert. Ein Nachteil durch das Anlegen von '''temp''' ergibt sich nicht, da das dafür verwendete Register für die Manipulation sowieso benötigt wird.

Wie alle Optimierungen kann dieses Vorgehen auch nach hinten losgehen: Wenn Laden und Zurückspeichern von '''var''' weit auseinanderliegen (extrem lange ISR), müllt man sich die Register zu. Im schlimmsten Fall wird '''temp''' sogar zwischenzeitlich auf dem Stack ausgelagert.

=== Schleifen ===

Bei Schleifen, die eine bestimmte Anzahl an Durchläufen ausgeführt werden sollen, ist es besser den Schleifenzähler vorher auf einen Wert zu setzen, und am Ende einer Do-While Schleife diesen zu dekrementieren.
So beschränkt sich die Sprungbedingung auf ein brne (branch if not equal).

Beispiel:
<syntaxhighlight lang="c">
uint8_t counter;
counter = 100;
do
{
// mach irgendetwas
} while (--counter);
</syntaxhighlight>

Achtung: Derartige Optimierungen sind meistens zweifelhaft und sehr Compilerabhängig. Compiler betreiben aufwendige Code- und Datenflussanalysen, in denen sie viele Dinge ins Kalkül ziehen, die ein menschlicher Programmierer im Regelfall nicht mehr überblicken kann. Von einem ordentlichen Compiler kann erwartet werden, dass er derartige Umstellungen (sofern sie möglich sind) in Eigenregie erledigt. Auch wenn es einzelne Compiler bzw. Compilerversionen gibt, in denen ein manueller Umbau einer derartigen Schleife tatsächlich eine Verbesserung bringt, sollte man immer im Hinterkopf behalten, dass sich in der nächsten Compilerversion alles umdrehen kann. Im Zweifelsfall lieber die Schleifenvariante benutzen, die der Situation angemessen ist und die den gewünschten Vorgang am klarsten beschreibt. Wenn dieser Vorgang im weitesten Sinne einen Countdown darstellt, dann ist natürlich nichts gegen eine derartige Schleifenkonstruktion einzuwenden.

=== Schiebeoperationen ===

Oft benötigt man Schiebeoperationen, um Daten Bit für Bit zu [[Bitmanipulation | verarbeiten]], z.B. für [http://www.mikrocontroller.net/articles/AVR-Tutorial:_Schieberegister Soft]-[[SPI]]. Hier empfiehlt es sich DRINGEND, möglichst nur Schiebeoperationen mit konstanten Verschiebungszähler durchzuführen, diese sind auf dem AVR deutlich schneller als Schiebeoperationen mit Variablen, welche meist durch mehrfache Funktionsaufrufe mit Scheifen etc. gelöst werden. Dabei verwendet man oft konstante Bitmasken, um die einzelnen Bits nacheinander zu maskieren.

Noch schneller geht das Schieben von Konstanten um einen konstanten Wert, denn das macht der Compiler bei eingeschalteter Optimierung noch während des Compilierens. Gerade für schnelle IO-Operationen kommt dann meist nur ein einziger ASM-Befehl heraus (sbi, cbi).

Ebenso ist es wenig empfehlenswert, 32 oder gar 64 Bit Datentypen zu schieben, das dauert sehr lange. Besser ist es, die Daten als Array von 8 Bit Werten zu handhaben und diese zu schieben, das ist meist deutlich schneller. Gute Beispiele findet man [http://www.mikrocontroller.net/topic/179566#1729219 hier] und [http://www.mikrocontroller.net/topic/169509#1631439 hier].

<syntaxhighlight lang="c">
#define DATAPORT PORTD
#define IO-BIT PD4

uint8_t a, b, i;

i=5
a = b << i; // variabler Verschiebewert, langsam
a = b << 5; // konstanter Verschiebewert, schnell

DATAPORT |= (1<<IO-BIT); // alles Konstanten, sehr schnell
</syntaxhighlight>

==Optimierung der Ausführungsgeschwindigkeit==

Hierzu gibt es schon eine Application-Note von Atmel. Diese AppNote bezieht sich auf den IAR-Compiler. Die darin genannten "Optimierungen" sind für avr-gcc größtenteils obsolet oder bleiben bestenfalls ohne Effekt.

Weblinks:
* [http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf AVR035]: Efficient C Coding for AVR
* [http://en.wikipedia.org/wiki/Program_optimization Program optimization] auf Wikipedia, engl.
* [http://bleaklow.com/2012/06/20/sensor_smoothing_and_optimised_maths_on_the_arduino.html Sensor smoothing and optimised maths on the Arduino] - Multiplikation vs. Division

== Fußnoten ==
<references/>

== Links ==
[http://www.atmel.com/Images/doc8453.pdf Atmel AVR4027]: Tips and Tricks to Optimize Your C Code for 8-bit AVR Microcontrollers ([http://www.atmel.com/Images/AVR4027.zip Beispiel-Code])

[[Category:avr-gcc]]

Entprellung

2015-07-08T12:47:57Z

Kbuchegg:

== Problembeschreibung ==
Mechanische [[Schalter]] wie [[Drehgeber]] neigen beim Ein- und Ausschalten zum sogenannten '''Prellen''', d.h sie schalten schnell mehrfach aus und ein, verursacht durch mechanische Vibrationen des Schaltkontaktes, sofern sie nicht dagegen geschützt sind. Vereinfacht dargestellt, sieht eine von einem Schalter oder Taster geschaltete Spannung beim Schalten wie folgt aus:

[[Bild:Entprellen.png]]

Für die Vermeidung bzw. Auswertung dieses unsauberen Signals gibt es verschiedene Ansätze:

== Hardwareentprellung ==

===Prellfreie Schalter===

Für Spezialanwendungen hält die elektromechanische Industrie verschiedene Sonderkonstruktionen bereit, die saubere Schaltzustände nach Aussen generieren, indem sie entweder eine mechanische Dämpfung in Form eines selbsthemmenden Federmechanismus oder eine integrierte elektronische Signalverzögerung benutzen.

Solche Systeme sind jedoch teuer und werden meist nur im Leistungsbereich eingesetzt.

===Wechselschalter===

Für die Entprellung von Wechselschaltern (engl. Double Throw Switch) kann ein klassisches RS-[[Flipflop]] genutzt werden. Bei dieser Variante werden neben zwei NAND-Gattern nur noch zwei Pull-Up Widerstände benötigt.

[[Bild:NAND_debouncer.png|thumb|left|350px|'''Taster entprellen mit NAND-RS-Flipflop''']]

 

In der gezeigten Schalterstellung liegt an der Position /S der Pegel 0 an. Damit ist das Flipflop gesetzt und der Ausgang auf dem Pegel 1. Schließt der Schalter zwischen den Kontakten 2 und 3, liegt an der Postion /R der Pegel 0 an. Dies bedeutet, dass der Ausgang des Flipflops auf den Pegel 0 geht. Sobald der Schalter von einem zum anderen Kontakt wechselt, beginnt er in der Regel zu prellen. Während des Prellens wechselt der Schalter zwischen den beiden Zuständen "Schalter berührt Kontakt" und "Schalter ist frei in der Luft". Der Ausgang des Flipflops bleibt in dieser Prellzeit aber stabil, da der Schalter während des Prellens nie den gegenüberliegenden Kontakt berührt und das RS-Flipflop seinen Zustand allein halten kann. Die Prellzeit ist stark vom Schaltertyp abhängig und liegt zwischen 0,1 und 10ms. Die Dimensionierung der Widerstände ist relativ unkritisch. Als Richtwert können hier 100kOhm verwendet werden.

====Wechselschalter ohne Flip-Flop====

Wenn man mal gerade kein Flip-Flop zur Hand hat, kann man sich auch mit dieser Schaltung behelfen.

[[Bild:WechselEntprellC.PNG|thumb|left|350px|'''Wechsler entprellen mit Kondensator''']]

 

Zur Funktionsweise:
Beim Umschalten wird der Kondensator immer sofort umgeladen.
Während der Kontakt prellt, befindet er sich in der Luft und hat keinerlei Verbindung. Während dieser Zeit übernimmt der Kondensator das halten des Pegels.

Dimensionierung:
Ist der entprellte Taster an ein IC Angeschlossen, ist der ''Input Leakage Current'' der ausschlaggebende Strom. Falls weitere Ströme fließen sind diese mit zu berücksichtigen. Bei einem Mikrocontroller von Atmel sind 1µA typisch.
Es gilt:
:<math>\frac{dU}{dt} = \frac{I}{C}</math>
Da eine Prellung ca. 10ms dauert und die Spannung in dieser Zeit beispielsweise um maximal 0,5V fallen soll kommt man auf folgende Kapazität:
:<math> C = \frac{I \cdot dt}{dU} = \frac{1\mu A \cdot 10ms}{0,5V} = 20nF </math>

Um Stromspitzen zu verringern kann ein Widerstand mit eingefügt werden. Eine Zeitkonstante von 1µs bis 1ms scheint sinnvoll. Also 500 Ohm bis 500kOhm sind nutzbar, wobei bei niedrigem Widerstand die Stromspitzen höher sind, und bei 500kOhm der Pinstrom störend wird.

===Einfacher Taster===

Auch wenn das RS-Flipflop sehr effektiv ist, wird diese Variante der Entprellung nur selten angewendet. Grund dafür ist, dass in Schaltungen häufiger einfache Taster eingesetzt werden. Diese sind oft kleiner und preisgünstiger. Um einfache Taster (engl. Single Throw Switch) zu entprellen, kann ein einfacher RC-Tiefpass eingesetzt werden. Hierbei wird ein Kondensator über einen Widerstand je nach Schalterstellung auf- oder entladen. Das RC-Glied bildet einen Tiefpass, sodass die Spannung über den Kondensator nicht von einen Pegel auf den anderen springen kann.

[[Bild:RC_debouncer.png|thumb|left|300px|Taster entprellen mit RC-Entpreller]]

[[Datei:Entprellen1a.png|thumb|350px| Entstehender Spannungsverlauf]]
{{Absatz}}

Wenn der Schalter geöffnet ist, lädt sich der Kondensator langsam über die beiden Widerstände R1 und R2 auf Vcc auf. Beim Erreichen der Umschaltschwelle springt der Ausgang auf den Pegel 0. Wird der Schalter geschlossen, entlädt sich der Kondensator langsam über den Widerstand R2. Demnach ändert sich der Ausgang des Inverters auf den Pegel 1. Während der Taster prellt, kann sich die Spannung über dem Kondensator nicht sprunghaft ändern, da das Auf- und Entladen eher langsam über die Widerstände erfolgt. Außerdem sind die Schaltschwellen für den Übergang LOW->HIGH und HIGH->LOW stark verschieden (Hysterese, siehe Artikel [[Schmitt-Trigger]]). Bei richtiger Dimensionierung der Bauelemente wird somit der Ausgang des Inverters prellfrei.

Zu beachten ist, dass der Inverter '''unbedingt''' einer mit [[Schmitt-Trigger]]-Eingängen sein muss, weil bei Standard-Logikeingängen im Bereich von üblicherweise 0,8V - 2,0V der Ausgang nicht definiert ist. Als Inverter kann zum Beispiel der 74HC14 oder der CD40106 (pinkompatibel) eingesetzt werden. Alternativ kann auch ein CD4093 eingesetzt werden. Bei dem CD4093 handelt es sich um NAND-Gatter mit Schmitt-Trigger-Eingängen. Um aus einem NAND-Gatter einen Inverter zu machen, müssen einfach nur die beiden Eingänge verbunden werden oder ein Eingang fest auf HIGH gelegt werden.

Für eine geeignete Dimensionierung muss man etwas mit den Standardformeln für einen Kondensator jonglieren. Die Spannung über den Kondensator beim Entladen berechnet sich nach:
:<math>U_C(t) = U_0 \cdot e^{\frac{-t}{R_2 C_1}}</math>

Damit der Ausgang des Inverters stabil ist, muss die Spannung über den Kondensator und damit die Spannung am Eingang des Inverters über der Spannung bleiben, bei welcher der Inverter umschaltet. Diese Schwellwertspannung ist genau die zeitabhängige Spannung über den Kondensator.
:<math>U_C(t)\!\ = U_{th}</math>

Durch Umstellen der Formel ergibt sich nun:
:<math>R_2=\frac{-t}{C_1 \cdot ln\left(\frac{U_{th}}{U_0} \right)}</math>

Ein Taster prellt üblicherweise etwa 10ms. Zur Sicherheit kann bei der Berechnung des Widerstandes eine Prellzeit von 20ms angenommen werden. U_0 ist die Betriebsspannung also Vcc. Die Schwellwertspannung muss aus dem Datenblatt des eingesetzten Schmitt-Triggers abgelesen werden. Beim 74HC14 beträgt der gesuchte Wert 2,0V. Nimmt man für den Kondensator 1µF und beträgt die Betriebsspannung 5V, ergibt sich für den Widerstand ein Wert von etwa 22kOhm.

Wird der Schalter geöffnet, lädt sich der Kondensator nach folgender Formel auf:
:<math>U_C(t) = U_0 \cdot \left( 1-e^{\frac{-t}{(R_1+R_2)\cdot C_1}} \right)</math>

Mit U_th=U_C ergibt das Umstellen nach (R_1+R_2):
:<math>R_1+R_2 = \frac{-t}{C_1 \cdot ln\left(1-\frac{U_{th}}{U_0} \right)} </math>

Für die Schwellspannung lässt sich aus dem Datenblatt ein Wert von 2,3V ablesen. Mit diesem Wert und den Annahmen von oben ergibt sich für R_1+R_2 ein Wert von 32kOhm. Somit ergibt sich für R_1 ein Wert von etwa 10kOhm.

Anmerkung: Beim 74LS14 von Hitachi z. B. sind die oberen und unteren Schaltschwellwerte unterschiedlich. Es muss darauf geachtet werden, dass U_{th} beim Entladen die untere Schwelle und U_{th} beim Laden die obere Schwelle einnimmt.

== Softwareentprellung ==

In den Zeiten der elektronischen Auswertung von Tastern und Schaltern ist das softwaretechnische Entprellen oft billiger, als die Benutzung eines teuren Schalters. Daher werden heute z.B. auch Computertastaturen nicht mehr mit prellarmen Tasten oder Entprellkondensatoren ausgestattet.

Bei Verwendung des in den meisten Geräten ohnehin vorhandenen Mikrocontrollers z.B., kann man sich die zusätzliche Hardware sparen, da die Entprellung in Software praktisch genauso gut funktioniert. Dabei ist nur zu beachten, dass zusätzliche Rechenleistung und je nach Umsetzung auch einige Hardwareressourcen (z.B. Timer) benötigt werden. Dafür hat man aber den Vorteil, das man kurze Fehlpulse, die offensichtlich keine Tastenbetätigung sein können sondern zb durch Einstreuungen hervorgerufen werden, einfach ausfiltern zu können.

=== Flankenerkennung ===
Bei einem Taster gibt es insgesamt 4 theoretische Zustände:

* 1. war nicht gedrückt und ist nicht gedrückt
* 2. war nicht gedrückt und ist gedrückt (steigende Flanke)
* 3. war gedrückt und ist immer noch gedrückt
* 4. war gedrückt und ist nicht mehr gedrückt (fallende Flanke)

Diese einzelnen Zustände lassen sich jetzt bequem abfragen/durchlaufen. Die Entprellung geschieht dabei durch die ganze Laufzeit des Programms. Die Taster werden hierbei als Active-Low angeschlossen, um die internen Pull-Ups zu nutzen.

Diese Routine gibt für den Zustand "steigende Flanke" den Wert "1" zurück, sonst "0"

<syntaxhighlight lang="c">
#define TASTERPORT PINC
#define TASTERBIT PINC1

char taster(void)
{
static unsigned char zustand;
char rw = 0;

if(zustand == 0 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gedrueckt (steigende Flanke)
{
zustand = 1;
rw = 1;
}
else if (zustand == 1 && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
else if (zustand == 2 && (TASTERPORT & (1<<TASTERBIT))) //Taster wird losgelassen (fallende Flanke)
{
zustand = 3;
rw = 0;
}
else if (zustand == 3 && (TASTERPORT & (1<<TASTERBIT))) //Taster losgelassen
{
zustand = 0;
rw = 0;
}

return rw;
}
</syntaxhighlight>

Eine Erweiterung, damit beliebig lange das Halten einer Taste erkannt wird kann man ganz einfach so implementieren:

<syntaxhighlight lang="c">
// zustand kann entweder zum ersten mal als gehalten detektiert werden oder aber jedes weitere mal
else if (((zustand == 1) || (zustand == 2)) && !(TASTERPORT & (1<<TASTERBIT))) //Taster wird gehalten
{
zustand = 2;
rw = 0;
}
</syntaxhighlight>

=== Warteschleifen-Verfahren ===

Soll nun mit einem Mikrocontroller gezählt werden, wie oft ein Kontakt oder ein Relais geschaltet wird, muss das Prellen des Kontaktes exakt berücksichtigt - und von einem gewollten Mehrfachschalten abgegrenzt werden, da sonst möglicherweise Fehlimpulse gezählt- oder andererseits echte Schaltvorgänge übersprungen werden. Dies muss beim Schreiben des Programms hinsichtlich des Abtastens des Kontaktes unbedingt Rechnung getragen werden.

Beim folgenden einfachen Beispiel für eine Entprellung ist zu beachten, dass der AVR im Falle eines Tastendrucks 200ms wartet, also brach liegt. Bei zeitkritischen Anwendungen sollte man ein anderes Verfahren nutzen (z. B. Abfrage der Tastenzustände in einer Timer-Interrupt-Service-Routine).

<syntaxhighlight lang="c">
#include <avr/io.h>
#include <inttypes.h>
#ifndef F_CPU
#warning "F_CPU war noch nicht definiert, wird nun mit 3686400 definiert"
#define F_CPU 3686400UL /* Quarz mit 3.6864 Mhz */
#endif
#include <util/delay.h> /* bei alter avr-libc: #include <avr/delay.h> */

/* Einfache Funktion zum Entprellen eines Tasters */
inline uint8_t debounce(volatile uint8_t *port, uint8_t pin)
{
if ( !(*port & (1 << pin)) )
{
/* Pin wurde auf Masse gezogen, 100ms warten */
_delay_ms(50); // Maximalwert des Parameters an _delay_ms
_delay_ms(50); // beachten, vgl. Dokumentation der avr-libc
if ( *port & (1 << pin) )
{
/* Anwender Zeit zum Loslassen des Tasters geben */
_delay_ms(50);
_delay_ms(50);
return 1;
}
}
return 0;
}

int main(void)
{
DDRB &= ~( 1 << PB0 ); /* PIN PB0 auf Eingang Taster) */
PORTB |= ( 1 << PB0 ); /* Pullup-Widerstand aktivieren */
...
if (debounce(&PINB, PB0))
{
/* Falls Taster an PIN PB0 gedrueckt */
/* LED an Port PD7 an- bzw. ausschalten: */
PORTD = PORTD ^ ( 1 << PD7 );
}
...
}
</syntaxhighlight>

Die obige Routine hat leider mehrere Nachteile:
* sie detektiert nur das Loslassen (unergonomisch)
* sie verzögert die Mainloop immer um 100ms bei gedrückter Taste
* sie verliert Tastendrücke, je mehr die Mainloop zu tun hat.

Eine ähnlich einfach zu benutzende Routine, aber ohne all diese Nachteile findet sich im Forenthread
[http://www.mikrocontroller.net/topic/164194#new Entprellung für Anfänger]

Der ''DEBOUNCE'' Befehl in dem BASIC-Dialekt BASCOM für AVR ist ebenfalls nach dem Warteschleifen-Verfahren programmiert. Die Wartezeit beträgt standardmäßig 25 ms, kann aber vom Anwender überschrieben werden. Vgl. [http://avrhelp.mcselec.com/bascom-avr.html?DEBOUNCE BASCOM Online-Manual zu DEBOUNCE].

Eine C-Implementierung für eine Tastenabfrage mit Warteschleife ist im Artikel [[AVR-GCC-Tutorial#IO-Register_als_Parameter_und_Variablen|AVR-GCC-Tutorial: IO-Register als Parameter und Variablen]] angeben.

Der Nachteil dieses Verfahrens ist, dass der Controller durch die Warteschleife blockiert wird. Günstiger ist die Implementierung mit einem Timer-Interrupt.

==== Warteschleifenvariante mit Maske und Pointer (nach Christian Riggenbach) ====

Hier eine weitere Funktion, um Taster zu entprellen: Durch den zusätzlichen Code kann eine Entprellzeit von durchschnittlich 1-3ms (mindestens 8*150µs = 1ms) erreicht werden. Grundsätzlich prüft die Funktion den Pegel der Pins auf einem bestimmten Port. Wenn die/der Pegel 8 Mal konstant war, wird die Schleife verlassen. Diese Funktion kann sehr gut eingesetzt werden, um in einer Endlosschleife Taster anzufragen, da sie, wie erwähnt, eine kurze Wartezeit hat.

<syntaxhighlight lang="c">
void entprellung( volatile uint8_t *port, uint8_t maske ) {
uint8_t port_puffer;
uint8_t entprellungs_puffer;

for( entprellungs_puffer=0 ; entprellungs_puffer!=0xff ; ) {
entprellungs_puffer<<=1;
port_puffer = *port;
_delay_us(150);
if( (*port & maske) == (port_puffer & maske) )
entprellungs_puffer |= 0x01;
}
}
</syntaxhighlight>
Die Funktion wird wie folgt aufgerufen:
<syntaxhighlight lang="c">
// Bugfix 20100414
// http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_port_pass
entprellung( &PINB, (1<<PINB2) ); // ggf. Prellen abwarten
if( PINB & (1<<PINB2) ) // dann stabilen Wert einlesen
{
// mach was
}
else
{
// mach was anderes
}
</syntaxhighlight>
Als Maske kann ein beliebiger Wert übergeben werden. Sie verhindert, dass nichtverwendete Taster die Entprellzeit negativ beeinflussen.

==== Debounce-Makro von Peter Dannegger ====

Peter Dannegger hat in [http://www.mikrocontroller.net/topic/164194#1566921 "Entprellen für Anfänger"] folgende vereinfachtes Entprellverfahren beschrieben. Das Makro arbeitet in der Originalversion mit ''active low'' geschalteten Tastern, kann aber einfach für ''active high'' geschaltete Taster angepasst werden ([[Pollin Funk-AVR-Evaluationsboard#Tasty Reloaded|Tasty Reloaded]]).

<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Not so powerful Debouncing Example */
/* No Interrupt needed */
/* */
/* Author: Peter Dannegger */
/* */
/************************************************************************/
// Target: ATtiny13

#include <avr/io.h>
#define F_CPU 9.6e6
#include <util/delay.h>

#define debounce( port, pin ) \
({ \
static uint8_t flag = 0; /* new variable on every macro usage */ \
uint8_t i = 0; \
\
if( flag ){ /* check for key release: */ \
for(;;){ /* loop ... */ \
if( !(port & 1<<pin) ){ /* ... until key pressed or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms released */ \
flag = 0; /* clear press flag */ \
i = 0; /* 0 = key release debounced */ \
break; \
} \
} \
}else{ /* else check for key press: */ \
for(;;){ /* loop ... */ \
if( (port & 1<<pin) ){ /* ... until key released or ... */ \
i = 0; /* 0 = bounce */ \
break; \
} \
_delay_us( 98 ); /* * 256 = 25ms */ \
if( --i == 0 ){ /* ... until key >25ms pressed */ \
flag = 1; /* set press flag */ \
i = 1; /* 1 = key press debounced */ \
break; \
} \
} \
} \
i; /* return value of Macro */ \
})

/*
Testapplication
*/
int main(void)
{
DDRB &= ~(1<<PB0);
PORTB |= 1<<PB0;
DDRB |= 1<<PB2;
DDRB &= ~(1<<PB1);
PORTB |= 1<<PB1;
DDRB |= 1<<PB3;
for(;;){
if( debounce( PINB, PB1 ) )
PORTB ^= 1<<PB2;
if( debounce( PINB, PB0 ) )
PORTB ^= 1<<PB3;
}
}

</syntaxhighlight>

Wenn das Makro für die gleiche Taste (Pin) an mehreren Stellen aufgerufen werden soll, muss eine Funktion angelegt werden, damit beide Aufrufe an die gleiche Zustandsvariable ''flag'' auswerten [http://www.mikrocontroller.net/topic/195914#1918727]:

<syntaxhighlight lang="c">
// Hilfsfunktion
uint8_t debounce_C1( void )
{
return debounce(PINC, PC1);
}

// Beispielanwendung
int main(void)
{
DDRB |= 1<<PB2;
DDRB |= 1<<PB3;
DDRC &= ~(1<<PC1);
PORTC |= 1<<PC1; // Pullup für Taster

for(;;){
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB2;
if( debounce_C1() ) // nicht: debounce(PINC, PC1)
PORTB ^= 1<<PB3;
}
}
</syntaxhighlight>

=== Timer-Verfahren (nach Peter Dannegger) ===

==== Grundroutine (AVR Assembler) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-20435.html#new Forum]

Vorteile
* besonders kurzer Code
* schnell

Außerdem können 8 Tasten (aktiv low) gleichzeitig bearbeitet werden, es dürfen also
alle exakt zur selben Zeit gedrückt werden. Andere Routinen können z. B. nur eine Taste verarbeiten, d.h. die zuerst oder zuletzt gedrückte gewinnt, oder es kommt Unsinn heraus.

Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen
kurz. Der entprellte Tastenzustand ist im Register ''key_state''. Mit nur 2 weiteren Instruktionen wird dann der Wechsel von ''Taste offen'' zu
''Taste gedrückt'' erkannt und im Register ''key_press'' abgelegt. Im Beispielcode werden dann damit 8 LEDs ein- und ausgeschaltet. Jede Taste entspricht einem Bit in den Registern, d.h. die Verarbeitung erfolgt bitweise mit logischen Operationen. Zum Verständnis empfiehlt es sich daher, die Logikgleichungen mit Gattern für ein Bit = eine Taste aufzumalen. Die Register kann man sich als Flipflops denken, die mit der Entprellzeit als Takt arbeiten. D.h. man kann das auch so z. B. in einem GAL22V10 realisieren.

Als Kommentar sind neben den einzelnen Instruktionen alle 8 möglichen
Kombinationen der 3 Signale dargestellt.

Beispielcode für AVR (Assembler):

<syntaxhighlight lang="avrasm">
.nolist
.include "c:\avr\inc\1200def.inc"
.list
.def save_sreg = r0
.def iwr0 = r1
.def iwr1 = r2

.def key_old = r3
.def key_state = r4
.def key_press = r5

.def leds = r16
.def wr0 = r17

.equ key_port = pind
.equ led_port = portb

rjmp init
.org OVF0addr ;timer interrupt 24ms
in save_sreg, SREG
get8key: ;/old state iwr1 iwr0
mov iwr0, key_old ;00110011 10101010 00110011
in key_old, key_port ;11110000
eor iwr0, key_old ; 11000011
com key_old ;00001111
mov iwr1, key_state ; 10101010
or key_state, iwr0 ; 11101011
and iwr0, key_old ; 00000011
eor key_state, iwr0 ; 11101000
and iwr1, iwr0 ; 00000010
or key_press, iwr1 ;store key press detect
;
; insert other timer functions here
;
out SREG, save_sreg
reti
;-------------------------------------------------------------------------
init:
ldi wr0, 0xFF
out ddrb, wr0
ldi wr0, 1<<CS02 | 1<<CS00 ;divide by 1024 * 256
out TCCR0, wr0
ldi wr0, 1<<TOIE0 ;enable timer interrupt
out TIMSK, wr0

clr key_old
clr key_state
clr key_press
ldi leds, 0xFF
main: cli
eor leds, key_press ;toggle LEDs
clr key_press ;clear, if key press action done
sei
out led_port, leds
rjmp main
;-------------------------------------------------------------
</syntaxhighlight>

==== Komfortroutine (C für AVR) ====

Siehe dazu: [http://www.mikrocontroller.net/forum/read-4-310276.html Forum]

'''Anmerkung''' Wenn statt active-low (Ruhezustand High) active-high (Ruhezustand Low) verwendet wird muss eine Zeile geändert werden siehe:
[http://www.mikrocontroller.net/forum/read-4-310276.html gesamter Beitrag im Forum],
[http://www.mikrocontroller.net/topic/48465#606555 Stelle 1 im Beitrag], ([http://www.mikrocontroller.net/topic/48465#2306398 Stelle 2 im Beitrag] muss *nicht* geändert werden, da hier die Polarität gar keinen Einfluß hat).

'''Anmerkung 2''' Zur Initialisierung siehe [http://www.mikrocontroller.net/topic/48465#3572793 Forum]

Funktionsprinzip wie oben plus zusätzliche Features:
* Kann Tasten sparen durch unterschiedliche Aktionen bei kurzem oder langem Drücken
* Wiederholfunktion, z. B. für die Eingabe von Werten

Das Programm ist für avr-gcc/avr-libc geschrieben, kann aber mit ein paar Anpassungen auch mit anderen Compilern und Mikrocontrollern verwendet werden. Eine Portierung für den AT91SAM7 findet man [http://www.google.com/codesearch?q=show:ac2viP-2E2Y:pzkOO5QRsoc:RPICuprYy-A&sa=N&cd=1&ct=rc&cs_p=svn://mikrocontroller.net/mp3dec/trunk&cs_f=keys.c#a0 hier] (aus dem Projekt [[ARM MP3/AAC Player]]).
<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Debouncing 8 Keys */
/* Sampling 4 Times */
/* With Repeat Function */
/* */
/* Author: Peter Dannegger */
/* danni@specs.de */
/* */
/************************************************************************/

#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>

#ifndef F_CPU
#define F_CPU 1000000 // processor clock frequency
#warning kein F_CPU definiert
#endif

#define KEY_DDR DDRB
#define KEY_PORT PORTB
#define KEY_PIN PINB
#define KEY0 0
#define KEY1 1
#define KEY2 2
#define ALL_KEYS (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

#define REPEAT_MASK (1<<KEY1 | 1<<KEY2) // repeat: key1, key2
#define REPEAT_START 50 // after 500ms
#define REPEAT_NEXT 20 // every 200ms

#define LED_DDR DDRA
#define LED_PORT PORTA
#define LED0 0
#define LED1 1
#define LED2 2

volatile uint8_t key_state; // debounced and inverted key state:
// bit = 1: key pressed
volatile uint8_t key_press; // key press detect

volatile uint8_t key_rpt; // key long press and repeat

ISR( TIMER0_OVF_vect ) // every 10ms
{
static uint8_t ct0, ct1, rpt;
uint8_t i;

TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms

i = key_state ^ ~KEY_PIN; // key changed ?
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
i &= ct0 & ct1; // count until roll over ?
key_state ^= i; // then toggle debounced state
key_press |= key_state & i; // 0->1: key press detect

if( (key_state & REPEAT_MASK) == 0 ) // check repeat function
rpt = REPEAT_START; // start delay
if( --rpt == 0 ){
rpt = REPEAT_NEXT; // repeat delay
key_rpt |= key_state & REPEAT_MASK;
}
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_press; // read key(s)
key_press ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed long enough such that the
// key repeat functionality kicks in. After a small setup delay
// the key is reported being pressed in subsequent calls
// to this function. This simulates the user repeatedly
// pressing and releasing the key.
//
uint8_t get_key_rpt( uint8_t key_mask )
{
cli(); // read and clear atomic !
key_mask &= key_rpt; // read key(s)
key_rpt ^= key_mask; // clear key(s)
sei();
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key is pressed right now
//
uint8_t get_key_state( uint8_t key_mask )

{
key_mask &= key_state;
return key_mask;
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_short( uint8_t key_mask )
{
cli(); // read key state and key press atomic !
return get_key_press( ~key_state & key_mask );
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_long( uint8_t key_mask )
{
return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
LED_PORT = 0xFF;
LED_DDR = 0xFF;

// Configure debouncing routines
KEY_DDR &= ~ALL_KEYS; // configure key port for input
KEY_PORT |= ALL_KEYS; // and turn on pull up resistors

TCCR0 = (1<<CS02)|(1<<CS00); // divide by 1024
TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5); // preload for 10ms
TIMSK |= 1<<TOIE0; // enable timer interrupt

sei();

while(1){
if( get_key_short( 1<<KEY1 ))
LED_PORT ^= 1<<LED1;

if( get_key_long( 1<<KEY1 ))
LED_PORT ^= 1<<LED2;

// single press and repeat

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
uint8_t i = LED_PORT;

i = (i & 0x07) | ((i << 1) & 0xF0);
if( i < 0xF0 )
i |= 0x08;
LED_PORT = i;
}
}
}
</syntaxhighlight>

Das single-press-und-repeat-Beispiel geht nicht in jeder Beschaltung; folgendes Beispiel sollte universeller sein (einzelne LED an/aus):
<syntaxhighlight lang="c">
// single press and repeat
if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 ))
LED_PORT ^=0x08;
</syntaxhighlight>

===== Funktionsweise =====
Der Code basiert auf 8 parallelen vertikalen Zählern, die über die Variablen ct0 und ct1 aufgebaut werden

[[Bild:VertCount.png|framed|center|'''8 vertikale Zähler in 2 8-Bit Variablen''']]

wobei jeweils ein Bit in ct0 mit dem gleichwertigen Bit in ct1 zusammengenommen einen 2-Bit-Zähler bildet.
Der Code der sich um die 8 Zähler kümmert, ist so geschrieben, daß er alle 8 Zähler gemeinsam parallel behandelt.

<syntaxhighlight lang="c">
i = key_state ^ ~KEY_PIN; // key changed ?
</syntaxhighlight>
i enthält an dieser Stelle für jede Taste, die sich im Vergleich mit dem vorhergehenden entprellten Zustand (keystate) verändert hat, ein 1 Bit.

<syntaxhighlight lang="c">
ct0 = ~( ct0 & i ); // reset or count ct0
ct1 = ct0 ^ (ct1 & i); // reset or count ct1
</syntaxhighlight>

Diese beiden Anweisungen erniedrigen den 2-Bit Zähler ct0/ct1 für jedes Bit um 1, welches in i gesetzt ist. Liegt an der entsprechenden Stelle in i ein 0 Bit vor (keine Änderung des Zustands), so wird der Zähler ct0/ct1 für dieses Bit auf 1 gesetzt.
Der Grundzustand des Zählers ist als ct0 == 1 und ct1 == 1 (Wert 3). Der Zähler zählt daher mit jedem ISR Aufruf, bei dem die Taste im Vergleich zu keystate als verändert erkannt wurde

ct1 ct0
1 1 // 3
1 0 // 2
0 1 // 1
0 0 // 0
1 1 // 3

<syntaxhighlight lang="c">
i &= ct0 & ct1; // count until roll over ?
</syntaxhighlight>
in i bleibt nur dort ein 1-Bit erhalten, wo sowohl in ct1 als auch in ct0 ein 1 Bit vorgefunden wird, der betreffende Zähler also bis 3 zählen konnte. Durch die zusätzliche Verundung mit i wird der Fall abgefangen, dass ein konstanter Zählerwert von 3 in i ein 1 Bit hinterlässt. Im Endergebnis bedeutet dass, dass nur ein Zählerwechsel von 0 auf 3 zu einem 1 Bit an der betreffenden Stelle in i führt, aber auch nur dann, wenn in i an dieser Bitposition ebenfalls ein 1 Bit war (welches wiederrum deswegen auf 1 war, weil an diesem Eingabeport eine Veränderung zum letzten bekannten entprellten Zustand festgestellt wurde). Alles zusammengenommen heißt das, dass ein Tastendruck dann erkannt wird, wenn die Taste 4 mal hintereinander in einem anderen Zustand vorgefunden wurde als dem zuletzt bekannten entprellten Tastenzustand.

An dieser Stelle ist i daher ein Vektor von 8 Bits, von denen jedes einzelne der Bits darüber Auskunft gibt, ob die entsprechende Taste mehrmals hintereinander im selben Zustand angetroffen wurde, der nicht mit dem zuletzt bekannten Tastenzustand übereinstimmt. Ist das der Fall, dann wird eine entsprechende Veränderung des Tastenzustands in key_state registriert
<syntaxhighlight lang="c">
key_state ^= i; // then toggle debounced state
</syntaxhighlight>
und wenn sich in key_state das entsprechende Bit von 0 auf 1 verändert hat, wird dieses Ereignis als 'Taste wurde niedergedrückt' gewertet.
<syntaxhighlight lang="c">
key_press |= key_state & i; // 0->1: key press detect
</syntaxhighlight>

Damit ist der Tasteneingang entprellt. Und zwar sowohl beim Drücken einer Taste als auch beim Loslassen (damit Tastenpreller beim Loslassen nicht mit dem Niederdrücken einer Taste verwechselt werden). Der weitere Code beschäftigt sich dann nur noch damit, diesen entprellten Tastenzustand weiter zu verarbeiten.

Der Codeteil sieht durch die Verwendung der vielen bitweisen Operationen relativ komplex aus. Behält man aber im Hinterkopf, dass einige der bitweisen wie ein 'paralles If' gleichzeitig auf allen 8 Bits eingesetzt werden, dann vereinfacht sich vieles. Ein
<syntaxhighlight lang="c">
key_press |= key_state & i;
</syntaxhighlight>
ist nichts anderes als ein
<syntaxhighlight lang="c">
// teste ob Bit 0 sowohl in key_state als auch in i gesetzt ist
// und setze Bit 0 in key_press, wenn das der Fall ist
if( ( key_state & ( 1 << 0 ) ) &&
( i & ( 1 << 0 ) )
key_press |= ( 1 << 0 );

// Bit 1
if( ( key_state & ( 1 << 1 ) ) &&
( i & ( 1 << 1 ) )
key_press |= ( 1 << 1 );

// Bit 2
if( ( key_state & ( 1 << 2 ) ) &&
( i & ( 1 << 2 ) )
key_press |= ( 1 << 2 );

...
</syntaxhighlight>
nur als wesentlich kompaktere Operation ausgeführt und für alle 8 Bits gleichzeitig.
Die Kürze und Effizienz dieser paar Codezeilen ergibt sich aus dem Umstand, dass jedes Bit in den Variablen für eine Taste steht und alle 8 (maximal möglichen) Tasten gleichzeitig die Operationen durchlaufen.

===== Reduziert auf lediglich 1 Taste =====
Diskussionen im Forum zeigen immer wieder, dass viele eine Abneigung gegen diesen Code haben, weil er ihnen sehr kompliziert vorkommt.

Der Code ist nicht leicht zu analysieren und er zieht alle Register dessen, was möglich ist, um sowohl Laufzeit als auch Speicherverbrauch einzusparen. Oft hört man auch das Argument: Ich benötige ja nur eine Entprellung für 1 Taste, gibt es da nichts Einfacheres?

Hier ist die 'Langform' des Codes, so wie man das für lediglich 1 Taste schreiben würde, wenn man exakt dasselbe Entprellverfahren einsetzen würde. Man sieht: Da ist keine Hexerei dabei: In key_state wird der letzte bekannte entprellte Zustand der Taste gehalten. Der Pin-Eingang wird mit diesem Zustand verglichen und wenn sich die beiden unterscheiden, dann wird ein Zähler heruntergezählt. Produziert dieses herunterzählen einen Unterlauf des Zählers, dann gilt die Taste als entprellt und wenn dann auch noch die Taste gerade gedrückt ist, dann wird dieses in key_press entsprechend vermerkt.

<syntaxhighlight lang="c">
uint8_t key_state;
uint8_t key_counter;
volatile uint8_t key_press;

ISR( ... Overflow ... )
{
uint8_t input = KEY_PIN & ( 1 << KEY0 );

if( input != key_state ) {
key_counter--;
if( key_counter == 0xFF ) {
key_counter = 3;
key_state = input;
if( input )
key_press = TRUE;
}
}
else
key_counter = 3;

}

uint8_t get_key_press()
{
uint8_t result;

cli();
result = key_press;
key_press = FALSE;
sei();

return result;
}
</syntaxhighlight>

Der vollständige Entprellcode, wie weiter oben gelistet, besticht jetzt aber darin, dass er compiliert kleiner ist als diese anschaulichere Variante für lediglich 1 Taste. Und das bei gleichzeitig erhöhter Funktionalität. Denn zb. ein Autorepeat ist in diesem Code noch gar nicht eingebaut. Und spätestens wenn man dann eine 2.te Taste entprellen möchte, dann ist auch der SRAM-Speicherverbrauch dieser Langform höher als der des Originals für 8 Tasten. Daraus folgt: Selbst für lediglich 1 Taste ist die Originalroutine die bessere Wahl.

Und wegen der Komplexität mal eine Frage: Sind Sie selbst in der Lage eine entsprechend effiziente sqrt() Funktion zu schreiben, wie die, die sie in der Standard-C-Bibliothek vorfinden? Nein? Dann dürften Sie eigentlich Ihrer Argumentation nach die Bibliotheksfunktion sqrt() nicht verwenden, sondern müssten sich statt dessen selbst eine Wurzel-Funktion schreiben.

=== Selbstsättigender Filter (nach Jürgen Schuhmacher) ===
Durch die Nutzung der diskreten Signalanalyse in Software kann die Funktionalität einer einfachen Entprellung mit einem Widerstand, einem Kondensator und einem Schmitttrigger wie in Hardware nachgebildet werden, indem ein abstrakter IIR-Filter benutzt wird, der eine Kondensatorladekurve emuliert. Mit der Vorschrift Y(t) = k Y(t-1) + Input wird ein einfaches Filter erzeugt, dass dem Eingangswert träge folgt. Bei Überschreiten eines bestimmten Wertes erfolgt mit einer einfachen Abfrage das Schalten des Ausgangssignals.

Für Assembler und VHDL bei FPGAs eignet sich aufgrund der leicht zu implementierenden binären Operationen folgende Darstellung mit einer Auflösung des Filterwertspeichers von nur 8 bit: Wert_Neu = Wert_Alt - Wert_Alt/16 + 16*(Taste = True). Der Filterwert bildet dann den gedämpften Verlauf des Eingangs (flankenverschliffen) ab und kann Prellen bis nahe an den Grenzbereich zum schnellen Tasten unterdrücken. Der Ausgangswert ist dann einfach das höchstwertige Bit des Filterwertes.

[[Datei:Entprellung mit IIR-Filter.gif]]

Dazu muss das Signal des Tasters idealerweise um den Faktor 10-20 schneller abgetastet werden, als die höchste gewünschte Tippgeschwindigkeit vorgibt. Noch schneller abzutasten ist möglich, führt aber zu mehr Bedarf an Bits beim Filter. Die Schmittriggerfunktion kann dadurch gebildet werden, dass eine 1 am Ausgang bei z.B. Überschreiten einer 55% Grenze und eine 0 bei Unterschreitung der 45%-Grenze ausgeben wird. Im Zwischenbereich wird der alte Wert gehalten.

=== Einfacher Mittelwertfilter (nach Lothar Miller) ===
Für digitale Schaltungen oder PLDs empfiehlt sich ein FIR-Filter mit aneinandergereihten FlipFlops. Man schiebt das Eingangssignal in eine FlipFlop-Kette und schaltet oberhalb der Mitte um:

SignalInput -> FF1 -> FF2 -> FF3 -> FF4 -> FF5 -> FF6 -> FF7 -> FF8

Wenn alle FFs = 1 (Summe der FFs=8) dann SignalOutput = 1 
Wenn alle FFs = 0 (Summe der FFs=0) dann SignalOutput = 0

Dieses Verfahren kann sehr einfach in Logik abgebildet werden, weil für die Berechnung des Ausgangs nur ein NOR bz. ein AND Gatter nötig ist.

== Gegenüberstellung der Verfahren ==
* HW - "entprellte Schalter": Sehr teuer, grosse Bauform, verschleissbelastet, geringe Haltbarkeit
* HW - "Umschalter" : benötigt aufwändigeren Schalter, benötigt Elektronik
* HW - "Umschalter ohne FF" : benötigt aufwändigeren Schalter und kleinen Kondensator
* HW - "Kondensatorentprellung" : benötigt etwas mehr Platz, kommt mit schlechten Schaltern zurecht

* SW - Flankenverfahren:
* SW - Warteschleife: Durch die Warteschleifen eine nicht zu vernachlässigende Verzögerung im Code. Speziell wenn mehrere Tasten zu überwachen sind, nicht unproblematisch
* SW - Timer: Universalfunktionalität, die durch geringen Speicherverbrauch, geringen Rechenzeitverbrauch und gute Funktion besticht. Der 'Verbrauch' eines Timers sieht auf den ersten Blick schlimmer aus, als er ist, denn in den meisten Programmen hat man sowieso einen Basistimer für die Zeitsteuerung des Programms im Einsatz, der für die Tastenentprellung mitbenutzt werden kann.
* SW - Filter: sehr geringer Platzbedarf in FPGAs, relativ gute Wirkung
* SW - Filter 2: sehr geringer Platzbedarf, gute Wirkung

== Links zum Thema ==

* [http://www.edn.com/design/analog/4324067/Contact-debouncing-algorithm-emulates-Schmitt-trigger Contact-debouncing algorithm (Artikel)], [http://www.edn.com/file/13370-70705di.pdf als PDF]
* [[AVR-Tutorial: Tasten]]
* [[AVR-GCC-Tutorial#.28Tasten-.29Entprellung|AVR-GCC-Tutorial Tastenentprellung]]
* [http://www.mikrocontroller.net/forum/read-4-20435.html Beitrag im Forum, AVR Assembler]
* [http://www.ganssle.com/debouncing.pdf A guide to debouncing (engl.), praktische Erläuterungen zum Entprellen in Soft- und Hardware]
* [http://www.pololu.com/docs/0J16/all Understanding Destructive LC Voltage Spikes]

[[Kategorie:AVR]]
[[Kategorie:Signalverarbeitung]]

AVR-GCC-Tutorial/Analoge Ein- und Ausgabe

2015-02-26T11:05:12Z

Kbuchegg: /* Nutzung des ADC */

Analoge Eingangswerte werden in der Regel über den AVR Analog-Digital-Converter (AD-Wandler, ADC) eingelesen, der in vielen Typen verfügbar ist (typisch 10bit Auflösung). Durch diesen werden analoge Signale (Spannungen) in digitale Zahlenwerte gewandelt. Bei AVRs, die über keinen internen AD-Wandler verfügen (z. B. ATmega162), kann durch externe Beschaltung (R/C-Netzwerk und Zeitmessung) die Funktion des AD-Wandlers simuliert werden.

Es gibt innerhalb der ATMega- und ATTiny-AVR Reihe keine Typen mit eingebautem Digital-Analog-Konverter (DAC) - diese Funktion ist erst ab der XMEGA-Reihe der AVR-Familie verfügbar, die aber wegen ihrer vielen Unterschiede im Umfang dieses Tutorials nicht behandelt wird.
Die Umsetzung zu einer analogen Spannung muss daher durch externe Komponenten vorgenommen werden. Das kann z. B. durch PWM und deren Filterung zu (fast) DC, oder einem sogenannten R2R-Netzwerk erfolgen.

Unabhängig davon besteht natürlich immer die Möglichkeit, spezielle Bausteine zur Analog-Digital- bzw. Digital-Analog-Wandlung zu nutzen und diese über eine digitale Schnittstelle (z.b. SPI oder I2C) mit einem AVR anzusteuern.

== AC (Analog Comparator) ==

Der Comparator vergleicht 2 Spannungen an den Pins AIN0 und AIN1 und gibt einen Status aus welche der beiden Spannungen größer ist. AIN0 Dient dabei als Referenzspannung (Sollwert) und AIN1 als Vergleichsspannung (Istwert). Als Referenzspannung kann auch alternativ eine interne Referenzspannung ausgewählt werden.

Liegt die Vergleichsspannung (IST) unter der der Referenzspannung (SOLL) gibt der Comparator eine logische 1 aus. Ist die Vergleichsspannung hingegen größer als die Referenzspannung wird eine logische 0 ausgegeben.

Der Comparator arbeitet völlig autark bzw. parallel zum Prozessor. Für mobile Anwendungen empfiehlt es sich ihn abzuschalten sofern er nicht benötigt wird, da er ansonsten Strom benötigt. Der Comparator kann interruptgesteuert abgefragt werden oder im Pollingbetrieb.

Das Steuer- bzw. Statusregister ist wie folgt aufgebaut:

{| class="wikitable" style="text-align:center"
|+ '''ACSR - Analog Comparator Status Register'''
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0
|-
! Name
| '''ACD'''|| '''ACBG'''|| '''ACO'''|| '''ACI'''|| '''ACIE'''|| '''ACIC'''|| '''ACIS1'''|| '''ACIS0'''
|-
! R/W
| R/W|| R/W|| R|| R/W|| R/W|| R/W|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| n/a|| 0|| 0|| 0|| 0|| 0
|}

;Bit 7 ACD: Analog Comparator Disable: 0 = Comparator ein, 1 = Comparator aus. Wird dieses Bit geändert kann ein Interrupt ausgelöst werden. Soll dies vermieden werden muss das Bit 3 ACIE ggf. abgeschaltet werden.

;Bit 6 ACBG: Analog Comparator Bandgap Select: Ermöglicht das umschalten zwischen interner und externer Referenzspannung. 1 = interne (~1,3 Volt), 0 = externe Referenzspannung (an Pin AIN0)

;Bit 5 ACO: Analog Comparator Output: Hier wird das Ergebnis des Vergleichs angezeigt. Es liegt typischerweise nach 1-2 Taktzyklen vor.
:: IST < SOLL → 1
:: IST > SOLL → 0

;Bit 4 ACI: Analog Comparator Interrupt Flag: Dieses Bit wird von der Hardware gesetzt, wenn ein Interruptereignis, das in Bit 0 und 1 definiert ist, eintritt. Dieses Bit löst noch keinen Interrupt aus! Die Interruptroutine wird nur dann ausgeführt, wenn das Bit 3 ACIE gesetzt ist und global Interrupts erlaubt sind (I-Bit in SREG gesetzt). Das Bit 4 ACI wird wieder gelöscht, wenn die Interruptroutine ausgeführt wurde oder wenn es manuell auf 1! gesetzt wird. Das Bit kann für Abfragen genutzt werden, steuert oder konfiguriert aber nicht den Comparator.

;Bit 3 ACIE: Analog Comparator Interrupt Enable: Ist das Bit auf 1 gesetzt, wird immer ein Interrupt ausgelöst, wenn das Ereignis das in Bit 1 und 0 definiert ist, eintritt.

;Bit 2 ACIC: Analog Comparator Input Capture Enable: Wird das Bit gesetzt, wird der Comparatorausgang intern mit dem Counter 1 verbunden. Es könnten damit z.b. die Anzahl der Vergleiche im Counter1 gezählt werden. Um den Comparator an den Timer1 Input Capture Interrupt zu verbinden, muss im Timerregister das TICIE1 Bit auf 1 gesetzt werden. Der Trigger wird immer dann ausgelöst, wenn das in Bit 1 und 0 definierte Ereignis eintritt.

;Bit 1,0 ACIS1,ACIS0: Analog Comparator Interrupt select: Hier wird definiert, welche Ereignisse einen Interrupt auslösen sollen:
:* 00 = Interrupt auslösen bei jedem Flankenwechsel
:* 10 = Interrupt auslösen bei fallender Flanke
:* 11 = Interrupt auslösen bei steigender Flanke

Werden diese Bit geändert, kann ein Interrupt ausgelöst werden. Soll dies vermieden werden, muss das Bit 3 gelöscht werden.

== ADC (Analog Digital Converter) ==

Der Analog-Digital-Konverter (ADC) wandelt analoge Signale in digitale Werte um, welche vom Controller interpretiert werden können. Einige AVR-Typen haben bereits einen mehrkanaligen Analog-Digital-Konverter eingebaut. Die Feinheit, mit welcher ein analoges Signal aufgelöst werden kann, wird durch die Auflösung des ADC, d.h. durch die Anzahl der verwendeten Bits angegeben. So sind derzeit bspw. 8-Bit- oder 10-Bit-ADC im Einsatz. ADCs, die in AVRs enthalten sind, haben zur Zeit eine maximale Auflösung von 10-Bit.

Ein ADC mit 8 Bit Auflösung kann somit das analoge Signal in Abstufungen von 1/256 des Maximalwertes digitalisieren. Wenn wir nun mal annehmen, wir hätten eine Eingangspannung zwischen 0 und 5 Volt, eine Referenzspannung von 5 V und eine Auflösung von 3 Bit, dann könnten
Intervalle mit den Grenzen 0 V, 0.625 V, 1.25 V, 1.875 V, 2.5 V, 3.125 V, 3.75 V, 4.375 V, 5 V entsprechend folgender Tabelle unterschieden werden:

::{| class="wikitable" style="text-align:center"
! Eingangsspannung am ADC / V || Entsprechender Messwert
|-
| 0 – 0.625 || 0
|-
| 0.625 – 1.25 || 1
|-
| 1.25 – 1.875 || 2
|-
| 1.875 – 2.5 || 3
|-
| 2.5 – 3.125 || 4
|-
| 3.125 – 3.75 || 5
|-
| 3.75 – 4.375 || 6
|-
| 4.375 – 5 || 7
|}

Die Angaben sind natürlich nur ungefähr. Je höher nun die Auflösung des Analog-Digital-Konverters ist, also, je mehr Bits er hat, desto genauer kann der jeweilige Wert erfasst werden.

=== Der interne ADC im AVR ===

Oft sind auch mehrere Kanäle verfügbar. Kanäle heißt in diesem Zusammenhang, dass zwar bis zu zehn analoge Eingänge am AVR vorhanden sind, aber nur ein "echter" Analog-Digital-Wandler zur Verfügung steht. Vor der eigentlichen Messung ist also festzulegen, welcher Kanal ("Pin") mit dem Wandler verbunden und gemessen wird.

Die Umwandlung innerhalb des AVR basiert auf der schrittweisen Näherung. Beim AVR müssen die Pins '''AGND''' und '''AVCC''' beschaltet werden. Für genaue Messungen sollte AVCC über ein L-C Netzwerk mit VCC verbunden werden, um Spannungsspitzen und -einbrüche vom Analog-Digital-Wandler fernzuhalten. Im Datenblatt findet sich dazu eine Schaltung, die 10µH und 100nF vorsieht.

Das Ergebnis der Analog-Digital-Wandlung wird auf eine Referenzspannung bezogen. Aktuelle AVRs bieten drei Möglichkeiten zur Wahl dieser Spannung:

* Eine externe Referenzspannung von maximal '''Vcc''' am Anschlusspin '''AREF'''. Die minimale (externe) Referenzspannung darf jedoch nicht beliebig niedrig sein, vgl. dazu das (aktuellste) Datenblatt des verwendeten Controllers.

* Verfügt der AVR über eine interne Referenzspannung, kann diese genutzt werden. Alle aktuellen AVRs mit internem AD-Wandler sollten damit ausgestattet sein (vgl. Datenblatt: 2,56V oder 1,1V je nach Typ). Das Datenblatt gibt auch über die Genauigkeit dieser Spannung Auskunft.

* Es kann die Spannung AVcc als Referenzspannung herangezogen werden

Bei Nutzung von AVcc oder der internen Referenz wird empfohlen, einen Kondensator zwischen dem AREF-Pin und GND anzuordnen. Die Festlegung, welche Spannungsreferenz genutzt wird, erfolgt z. B. beim ATmega16 mit den Bits REFS1/REFS0 im ADMUX-Register. Die zu messende Spannung muss im Bereich zwischen '''AGND''' und '''AREF''' (egal ob intern oder extern) liegen.

Der '''ADC''' kann in zwei verschiedenen Betriebsarten verwendet werden:

; Einfache Wandlung (Single Conversion) : In dieser Betriebsart wird der Wandler bei Bedarf vom Programm angestoßen für jeweils eine Messung.

; Frei laufend (Free Running) : In dieser Betriebsart erfasst der Wandler permanent die anliegende Spannung und schreibt diese in das '''ADC Data Register'''.

==== Die Register des ADC ====

Der '''ADC''' verfügt über eigene Register. Im Folgenden die Registerbeschreibung eines ATMega16, welcher über 8 ADC-Kanäle verfügt. Die Register unterscheiden sich jedoch nicht erheblich von denen anderer AVRs (vgl. Datenblatt).

{| class="wikitable"
|-
| width="100" | '''ADCSRA   '''
| '''ADC''' '''C'''ontrol and '''S'''tatus '''R'''egister A. 
In diesem Register stellen wir ein, wie wir den '''ADC''' verwenden möchten. 
Das Register ist wie folgt aufgebaut:

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0
|-
! Name
| '''ADEN'''|| '''ADSC'''|| '''ADFR'''|| '''ADIF'''|| '''ADIE'''|| '''ADPS2'''|| '''ADPS1'''|| '''ADPS0'''
|-
! R/W
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''ADEN''' ('''AD'''C '''En'''able)
:Dieses Bit muss gesetzt werden, um den ''' ADC''' überhaupt zu aktivieren. Wenn das Bit nicht gesetzt ist, können die Pins wie normale I/O-Pins verwendet werden.

'''ADSC''' ('''AD'''C '''S'''tart '''C'''onversion)
:Mit diesem Bit wird ein Messvorgang gestartet. In der frei laufenden Betriebsart muss das Bit gesetzt werden, um die kontinuierliche Messung zu aktivieren.
:Wenn das Bit nach dem Setzen des '''ADEN'''-Bits zum ersten Mal gesetzt wird, führt der Controller zuerst eine zusätzliche Wandlung und erst dann die eigentliche Wandlung aus. Diese zusätzliche Wandlung wird zu Initialisierungszwecken durchgeführt.
:Das Bit bleibt nun so lange auf 1, bis die Umwandlung abgeschlossen ist, im Initialisierungsfall entsprechend bis die zweite Umwandlung erfolgt ist und geht danach auf 0.

'''ADFR''' ('''AD'''C '''F'''ree '''R'''un select)
:Mit diesem Bit wird die Betriebsart eingestellt.
:Ist das Bit auf 1 gesetzt arbeitet der ADC im "Free Running"-Modus. Dabei wird das Datenregister permanent aktualisiert. Ist das Bit hingegen auf 0 gesetzt, macht der ADC nur eine "Single Conversion".

'''ADIF''' ('''AD'''C '''I'''nterrupt '''F'''lag)
:Dieses Bit wird vom ''' ADC''' gesetzt, sobald eine Umwandlung erfolgt ist und das '''ADC Data Register''' aktualisiert wurde.
:Wenn das '''ADIE''' Bit sowie das '''I-Bit''' im AVR '''Statusregister''' gesetzt ist, wird der '''ADC Interrupt''' ausgelöst und die Interrupt-Behandlungsroutine aufgerufen.
:Das Bit wird automatisch gelöscht, wenn die Interrupt-Behandlungsroutine aufgerufen wird. Es kann jedoch auch gelöscht werden, indem eine logische '''1'''! in das Register geschrieben wird.

'''ADIE''' ('''AD'''C '''I'''nterrupt '''E'''nable)
:Wenn dieses Bit gesetzt ist und ebenso das ''' I-Bit''' im Statusregister '''SREG''', dann wird der ''' ADC-Interrupt''' aktiviert.

'''ADPS2...ADPS0''' ('''AD'''C '''P'''rescaler '''S'''elect Bits)
:Diese Bits bestimmen den Teilungsfaktor zwischen der Taktfrequenz und dem Eingangstakt des '''ADC'''.
:Der '''ADC''' benötigt einen eigenen Takt, welchen er sich selber aus der CPU-Taktfreqenz erzeugt. Der '''ADC'''-Takt sollte zwischen 50 und 200kHz liegen.
:Der Vorteiler muss also so eingestellt werden, dass CPU-Taktfrequenz dividiert durch den Teilungsfaktor einen Wert im Bereich '''(50-200)kHz''' ergibt.
:Bei einer CPU-Taktfrequenz von 4MHz beispielsweise rechnen wir

:<math>
\begin{matrix}
TF_{min}=\frac{CLK}{200\,\mathrm{kHz}}=\frac{4000000}{200000}=\mathbf{20}
\\
\\
TF_{max}=\frac{CLK}{50\,\mathrm{kHz}}=\frac{4000000}{50000}=\mathbf{80}
\end{matrix}
</math>

:Somit kann hier der Teilungsfaktor 32 oder 64 verwendet werden. Im Interesse der schnelleren Wandlungszeit werden wir hier den Faktor 32 einstellen.

:{| class="wikitable" style="text-align:center"
|-
! '''ADPS2'''|| '''ADPS1'''|| '''ADPS0'''|| '''Teilungsfaktor'''
|-
| 0|| 0|| 0|| 2
|-
| 0|| 0|| 1|| 2
|-
| 0|| 1|| 0|| 4
|-
| 0|| 1|| 1|| 8
|-
| 1|| 0|| 0|| 16
|-
| 1|| 0|| 1|| 32
|-
| 1|| 1|| 0|| 64
|-
| 1|| 1|| 1|| 128
|}

|-
| '''ADCL''' 
'''ADCH'''
| '''ADC ''' Data Register 
Wenn eine Umwandlung abgeschlossen ist, befindet sich der gemessene Wert in
diesen beiden Registern. Von '''ADCH''' werden nur die beiden niederwertigsten Bits verwendet. Es müssen immer beide Register ausgelesen werden, und zwar immer '''in der Reihenfolge: ADCL, ADCH'''.
Der effektive Messwert ergibt sich dann zu:

<syntaxhighlight lang="c">
x = ADCL; // mit uint16_t x
x += (ADCH<<8); // in zwei Zeilen (LSB/MSB-Reihenfolge und
// C-Operatorpriorität sichergestellt)
</syntaxhighlight>

oder

<syntaxhighlight lang="c">
x = ADCW; // je nach AVR auch x = ADC (siehe avr/ioxxx.h)
</syntaxhighlight>

|-
| '''ADMUX  '''
| '''AD'''C '''Mu'''ltiple'''x'''er Select Register 
Mit diesem Register wird der zu messende Kanal ausgewählt. Beim 90S8535
kann jeder Pin von Port A als '''ADC'''-Eingang verwendet werden (=8 Kanäle). 
Das Register ist wie folgt aufgebaut:

{| class="wikitable" style="text-align:center"
|-
! Bit
| 7|| 6|| 5|| 4|| 3|| 2|| 1|| 0
|-
! Name
| '''REFS1'''|| '''REFS0'''|| '''ADLAR'''|| '''MUX4'''|| '''MUX3'''|| '''MUX2'''|| '''MUX1'''|| '''MUX0'''
|-
! '''R/W'''
| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W|| R/W
|-
! Initialwert
| 0|| 0|| 0|| 0|| 0|| 0|| 0|| 0
|}

'''REFS1...REFS0''' ('''Ref'''erence'''S'''election Bits)
:Mit diesen Bits kann die Referenzspannung eingestellt werden. Bei der Umstellung sind Wartezeiten zu beachten, bis die ADC-Hardware einsatzfähig ist (Datenblatt und [http://www.mikrocontroller.net/topic/165513]):

{| class="wikitable" style="text-align:center"
|-
! '''REFS1'''|| '''REFS0'''|| '''Referenzspanung'''
|-
| 0|| 0|| Externes AREF
|-
| 0|| 1|| AVCC als Referenz
|-
| 1|| 0|| Reserviert
|-
| 1|| 1|| Interne 2,56 Volt
|}

:Beim ATtiny25, ATtiny45 und ATtiny85 gilt:
{| class="wikitable" style="text-align:center"
|-
! '''REFS2'''||'''REFS1'''|| '''REFS0'''|| '''Referenzspanung'''
|-
| X || 0|| 0|| VCC als Referenz
|-
| X || 0|| 1|| Externes AREF
|-
| X || 1|| 0|| Interne 1,1 Volt
|-
| X || 1|| 1|| Reserviert
|-
| 1 || 1|| 0|| Interne 2,56 Volt
|-
| 1 || 1|| 1|| Interne 2,56 Volt mit bypass Kapazität am AREF Pin
|}

'''ADLAR''' ('''ADC ''' '''L'''eft '''A'''djust '''R'''esult)
:Das ADLAR Bit verändert das Aussehen des Ergebnisses der AD-Wandlung. Bei einer logischen 1 wird das Ergebnis linksbündig ausgegeben, bei einer 0 rechtsbündig. Eine Änderung in diesem Bit beeinflusst das Ergebnis sofort, ganz egal ob bereits eine Wandlung läuft.

'''MUX4...MUX0'''
:Mit diesen 5 Bits wird der zu messende Kanal bestimmt. Wenn man einen einfachen 1-kanaligen ADC verwendet wird einfach die entsprechende Pinnummer des Ports in die Bits 0...4 eingeschrieben (je nach Anzahl der Wandler des AVR, bei 8 AD-Kanälen halt nur 0...2).
:Wenn das Register beschrieben wird, während eine Umwandlung läuft, so wird zuerst die aktuelle Umwandlung auf dem bisherigen Kanal beendet. Dies ist vor allem beim frei laufenden Betrieb zu berücksichtigen.

:Eine Empfehlung ist deswegen diese, dass der frei laufende Betrieb nur bei einem einzelnen zu verwendenden Analogeingang verwendet werden sollte, wenn man sich Probleme bei der Umschalterei ersparen will.
|}

==== Nutzung des ADC ====

Um den ''' ADC''' zu aktivieren, müssen wir das '''ADEN'''-Bit im '''ADCSRA'''-Register setzen. Im gleichen Schritt legen wir auch die Betriebsart fest.

Im Folgenden ein kleines Beispiel für den "single conversion"-Mode bei einem ATmega169 und Nutzung der internen Referenzspannung (beim '169 1,1V bei anderen AVRs auch 2,56V, vgl. Datenblatt). D.h. das Eingangssignal darf diese Spannung nicht überschreiten, gegebenenfalls muss es mit einem [[Spannungsteiler]] verringert werden. Das Ergebnis der Routine ist der ADC-Wert, also 0 für 0-Volt und 1023 für V_ref-Volt. Beim Programmstart wir der ADC konfiguriert und aktiviert und dann auf verschiedenen Kanälen die Spannung gemessen. Initialisierung des ADC und die Wandlungen sollte man trennen, denn das Einschalten des ADC und vor allem der Referenzspannung dauert ein paar Dutzend Mikrosekunden. Außerdem ist das erste Ergebnis nach dem Einschalten ungültig und muss verworfen werden.

<syntaxhighlight lang="c">
// Diese Beispiel zeigt die Anwendung des ADC eines ATmega169
// unter Verwendung der internen Referenzspannung von nominell 1,1V.
// Zur Anpassung an andere AVR und/oder andere Referenzspannungen
// siehe Erläuterungen in diesem Tutorial und im Datenblatt

/* ADC initialisieren */
void ADC_Init(void)
{
// die Versorgungsspannung AVcc als Refernz wählen:
ADMUX = (1<<REFS0);
// oder interne Referenzspannung als Referenz für den ADC wählen:
// ADMUX = (1<<REFS1) | (1<<REFS0);

// Bit ADFR ("free running") in ADCSRA steht beim Einschalten
// schon auf 0, also single conversion
ADCSRA = (1<<ADPS1) | (1<<ADPS0); // Frequenzvorteiler
ADCSRA |= (1<<ADEN); // ADC aktivieren

/* nach Aktivieren des ADC wird ein "Dummy-Readout" empfohlen, man liest
also einen Wert und verwirft diesen, um den ADC "warmlaufen zu lassen" */

ADCSRA |= (1<<ADSC); // eine ADC-Wandlung
while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten
}
/* ADCW muss einmal gelesen werden, sonst wird Ergebnis der nächsten
Wandlung nicht übernommen. */
(void) ADCW;
}

/* ADC Einzelmessung */
uint16_t ADC_Read( uint8_t channel )
{
// Kanal waehlen, ohne andere Bits zu beeinflußen
ADMUX = (ADMUX & ~(0x1F)) | (channel & 0x1F);
ADCSRA |= (1<<ADSC); // eine Wandlung "single conversion"
while (ADCSRA & (1<<ADSC) ) { // auf Abschluss der Konvertierung warten
}
return ADCW; // ADC auslesen und zurückgeben
}

/* ADC Mehrfachmessung mit Mittelwertbbildung */
/* beachte: Wertebereich der Summenvariablen */
uint16_t ADC_Read_Avg( uint8_t channel, uint8_t nsamples )
{
uint32_t sum = 0;

for (uint8_t i = 0; i < nsamples; ++i ) {
sum += ADC_Read( channel );
}

return (uint16_t)( sum / nsamples );
}

...

/* Beispielaufrufe: */

int main( void )
{
uint16_t adcval;
ADC_Init();

while( 1 ) {
adcval = ADC_Read(0); // Kanal 0
// mach was mit adcval

adcval = ADC_Read_Avg(2, 4); // Kanal 2, Mittelwert aus 4 Messungen
// mach was mit adcval
}
}

</syntaxhighlight>

Im Beispiel läuft der ADC ständig. Für den Fall, dass man Strom sparen will, z.B. mittels Verwendung des [[Sleep Mode]]s, muss man den ADC nach jeder Messung abschalten und vor der nächsten Messung wieder einschalten, wobei auch dann wieder eine kleine Pause und Anfangswandlung nötig sind.



==== Externe Referenzspannung ====

Die minimale (externe) Referenzspannung des ADC darf nicht beliebig niedrig sein, vgl. dazu das (aktuellste) Datenblatt des verwendeten Controllers. z. B. beim ATmega8 darf sie laut Datenblatt<ref>ATmega8: S.245, Tabelle 103, Zeile "VREF"</ref> 2,0V nicht unterschreiten.<ref>Diese Information findet sich erst in der letzten Revision (Rev. 2486O-10/04) des Datenblatts.</ref>

Meiner  eigenen Erfahrung nach kann man aber (auf eigene Gefahr und natürlich nicht für Seriengeräte) durchaus noch ein klein wenig weiter heruntergehen, bei dem von mir unter die Lupe genommenen ATmega8L (also die Low-Voltage-Variante) funktioniert der ADC bei 5V Betriebsspannung mit bis zu VREF=1,15V hinunter korrekt, ab 1,1V und darunter digitalisiert er jedoch nur noch Blödsinn). Ich würde sicherheitshalber nicht unter 1,5V gehen und bei niedrigeren Betriebsspannungen mag sich die Untergrenze für VREF am Pin AREF ggf. nach ''oben'' verschieben.

In der letzten Revision des Datenblatts ist außerdem korrigiert, dass ADC4 und ADC5 sehr wohl 10 Bit Genauigkeit bieten — und nicht bloß 8 Bit, wie in älteren Revisionen irrtümlich angegeben.

=== Analog-Digital-Wandlung ohne internen ADC ===

==== Messen eines Widerstandes ====

[[Image:Poti.gif|framed|right]]
Analoge Werte lassen sich ohne Analog-Digital-Wandler auch indirekt ermitteln. Im Folgenden wird die Messung des an einem Potentiometer eingestellten Widerstands anhand der Ladekurve eines Kondensators erläutert. Bei dieser Methode wird nur ein Portpin benötigt, ein Analog-Digital-Wandler oder Analog-Comparator ist nicht erforderlich. Es wird dazu ein Kondensator und der Widerstand (das Potentiometer) in Reihe zwischen Vorsorgungsspannung und Masse/GND geschaltet (sogen. RC-Netzwerk). Zusätzlich wird eine Verbindung der Leitung zwischen Kondensator und Potentiometer zu einem Portpin des Controllers hergestellt. Die folgende Abbildung verdeutlicht die erforderliche Schaltung.

Wird der Portpin des Controllers auf Ausgang konfiguriert (im Beispiel ''DDRD |= (1<<PD2)'') und dieser Ausgang auf Logisch 1 ("High", ''PORTD |= (1<<PD2)'') geschaltet, liegt an beiden "Platten" des Kondensators das gleiche Potential '''VCC''' an und der Kondensator somit entladen. (Klingt komisch, mit ''' Vcc''' entladen, ist aber so, da an beiden Seiten des Kondensators das gleiche Potential anliegt und somit eine Potentialdifferenz von 0V besteht => Kondensator ist entladen).

Nach einer gewissen Zeit ist der Kondensator entladen und der Portpin wird als Eingang konfiguriert (''DDRD &= ~(1<<PD2); PORTD &= ~(1<<PD2)''), wodurch dieser hochohmig wird. Der Status des Eingangspin (in PIND) ist Logisch 1 (High). Der Kondensator lädt sich jetzt über das Poti auf, dabei steigt der Spannungsabfall über dem Kondensator und derjenige über dem Poti sinkt. Fällt nun der Spannungsabfall über dem Poti unter die Threshold-Spannung des Eingangspins (2/5 Vcc, also ca. 2V), wird das Eingangssignal als LOW erkannt (Bit in PIND wird 0). Die Zeitspanne zwischen der Umschaltung von Entladung auf Aufladung und dem Wechsel des Eingangssignals von High auf Low ist ein Maß für den am Potentiometer eingestellten Widerstand. Zur Zeitmessung kann einer der im Controller vorhandenen Timer genutzt werden. Der 220Ω Widerstand dient dem Schutz des Controllers. Es würde sonst bei Maximaleinstellung des Potentionmeters (hier 0Ω) ein zu hoher Strom fließen, der die Ausgangsstufe des Controllers zerstört.

Mit einem weiteren Eingangspin und ein wenig Software können wir auch eine Kalibrierung realisieren, um den Messwert in einen vernünftigen Bereich (z.B: 0...100 % oder so) umzurechnen.



==== ADC über Komparator ====

[[Image:ADC ueber Komparator.gif|framed|right]]
Es gibt einen weiteren Weg, eine analoge Spannung mit Hilfe des
Komparators, welcher in fast jedem AVR integriert ist, zu messen. Siehe dazu
auch die Application Note AVR400 von Atmel.

Dabei wird das zu messende Signal auf den invertierenden Eingang
des Komparators geführt. Zusätzlich wird ein Referenzsignal an den nicht
invertierenden Eingang des Komparators angeschlossen. Das Referenzsignal wird
hier auch wieder über ein RC-Glied erzeugt, allerdings mit festen Werten für R
und C.

Das Prinzip der Messung ist nun dem vorhergehenden recht
ähnlich. Durch Anlegen eines LOW-Pegels an Pin 2 wird der Kondensator zuerst
einmal entladen. Auch hier muss darauf geachtet werden, dass der Entladevorgang
genügend lang dauert.
Nun wird Pin 2 auf HIGH gelegt. Der Kondensator wird geladen. Wenn die Spannung
über dem Kondensator die am Eingangspin anliegende Spannung erreicht hat,
schaltet der Komparator durch. Die Zeit, welche benötigt wird, um den
Kondensator zu laden, kann nun auch wieder als Maß für die Spannung an Pin 1
herangezogen werden.

Ich habe es mir gespart, diese Schaltung auch aufzubauen, und zwar aus mehreren Gründen:

# 3 Pins notwendig.
# Genauigkeit vergleichbar mit einfacherer Lösung.
# War einfach zu faul.

Der Vorteil dieser Schaltung liegt allerdings darin, dass damit direkt Spannungen gemessen werden können.

== DAC (Digital Analog Converter) ==

Mit Hilfe eines Digital-Analog-Konverters ('''DAC''') können wir nun auch Analogsignale ausgeben. Es gibt hier mehrere Verfahren. 

=== DAC über mehrere digitale Ausgänge ===

Wenn wir an den Ausgängen des Controllers ein entsprechendes
Widerstandsnetzwerk aufbauen haben wir die Möglichkeit, durch die Ansteuerung
der Ausgänge über den Widerständen einen Addierer aufzubauen, mit dessen
Hilfe wir eine dem Zahlenwert proportionale Spannung erzeugen können. Das
Schaltbild dazu kann etwa so aussehen:

[[Image:DAC R2R.gif]]

Es sollten selbstverständlich möglichst genaue Widerstände verwendet
werden, also nicht unbedingt solche mit einer Toleranz von 10% oder mehr.
Weiterhin empfiehlt es sich, je nach Anwendung den Ausgangsstrom über einen
Operationsverstärker zu verstärken.

=== PWM (Pulsweitenmodulation) ===

Wir kommen nun zu einem Thema, welches in aller Munde ist, aber viele
Anwender verstehen nicht ganz, wie [[PWM]] eigentlich funktioniert.

Wie wir alle wissen, ist ein Mikrocontroller ein rein digitales Bauteil.
Definieren wir einen Pin als Ausgang, dann können wir diesen Ausgang entweder
auf HIGH setzen, worauf am Ausgang die Versorgungsspannung ''' Vcc''' anliegt, oder aber wir setzen den Ausgang auf LOW, wonach dann ''' 0V''' am Ausgang liegt. Was passiert aber nun, wenn wir periodisch mit einer festen Frequenz zwischen HIGH und LOW umschalten? - Richtig, wir erhalten eine Rechteckspannung, wie die folgende Abbildung zeigt:

[[Image:PWM Theorie 1.gif]]

Diese Rechteckspannung hat nun einen arithmetischen Mittelwert,
der je nach Pulsbreite kleiner oder größer ist.

[[Image:PWM Theorie 2.gif]]

Wenn wir nun diese pulsierende Ausgangsspannung noch über ein RC-Glied filtern/"glätten", dann haben wir schon eine entsprechende Gleichspannung erzeugt.

Mit den AVRs können wir direkt PWM-Signale erzeugen.
Dazu dient der 16-Bit Zähler, welcher im sogenannten PWM-Modus betrieben werden kann.

;Hinweis: In den folgenden Überlegungen wird als Controller der 90S2313 vorausgesetzt. Die Theorie ist bei anderen AVR-Controllern vergleichbar, die Pinbelegung allerdings nicht unbedingt, weshalb ein Blick ins entsprechende Datenblatt dringend angeraten wird.

Um den PWM-Modus zu aktivieren, müssen im Timer/Counter1 Control
Register A TCCR1A die Pulsweiten-Modulatorbits PWM10 bzw. PWM11 entsprechend nachfolgender Tabelle gesetzt werden:

{| class="wikitable" style="text-align:center"
|-
! PWM11 || PWM10 || Bedeutung
|-
| 0 || 0 || PWM-Modus des Timers ist nicht aktiv
|-
| 0 || 1 || 8-Bit PWM
|-
| 1 || 0 || 9-Bit PWM
|-
| 1 || 1 || 10-Bit PWM
|}

Der Timer/Counter zählt nun permanent von 0 bis zur Obergrenze
und wieder zurück, er wird also als sogenannter Auf-/Ab Zähler betrieben.
Die Obergrenze hängt davon ab, ob wir mit 8, 9 oder 10-Bit PWM arbeiten wollen:

{| class="wikitable"
|-
! Auflösung || Obergrenze || Frequenz
|-
| align="center" | 8
| align="center" | 255
| fTC1 / 510
|-
| align="center" | 9
| align="center" | 511
| fTC1 / 1022
|-
| align="center" | 10
| align="center" | 1023
| fTC1 / 2046
|}

Zusätzlich muss mit den Bits '''COM1A1''' und '''COM1A0''' desselben
Registers die gewünschte Ausgabeart des Signals definiert werden:

{| class="wikitable"
|-
! COM1A1 || COM1A0 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| Keine Wirkung, Pin wird nicht geschaltet.
|-
| align="center" | 0
| align="center" | 1
| Keine Wirkung, Pin wird nicht geschaltet.
|-
| align="center" | 1
| align="center" | 0
| Nicht invertierende PWM. 
Der Ausgangspin wird gelöscht beim Hochzählen und gesetzt beim
Herunterzählen.
|-
| align="center" | 1
| align="center" | 1
| Invertierende PWM. 
Der Ausgangspin wird gelöscht beim Herunterzählen und gesetzt beim
Hochzählen.
|}

Der entsprechende Befehl, um beispielsweise den Timer/Counter als
nicht invertierenden 10-Bit PWM zu verwenden, heißt dann:

alte Schreibweise (PWMxx wird nicht mehr akzeptiert)
<syntaxhighlight lang="c">
TCCR1A = (1<<PWM11)|(1<<PWM10)|(1<<COM1A1);
</syntaxhighlight>
neue Schreibweise
<syntaxhighlight lang="c">
TCCR1A = (1<<WGM11)|(1<<WGM10)|(1<<COM1A1);
</syntaxhighlight>

Damit der Timer/Counter überhaupt läuft, müssen wir im Control
Register B '''TCCR1B''' noch den gewünschten Takt (Vorteiler) einstellen und
somit auch die Frequenz des '''PWM'''-Signals bestimmen.

{| class="wikitable"
|-
! CS12 || CS11 || CS10 || Bedeutung
|-
| align="center" | 0
| align="center" | 0
| align="center" | 0
| Stop. Der Timer/Counter wird gestoppt.
|-
| align="center" | 0
| align="center" | 0
| align="center" | 1
| CK
|-
| align="center" | 0
| align="center" | 1
| align="center" | 0
| CK / 8
|-
| align="center" | 0
| align="center" | 1
| align="center" | 1
| CK / 64
|-
| align="center" | 1
| align="center" | 0
| align="center" | 0
| CK / 256
|-
| align="center" | 1
| align="center" | 0
| align="center" | 1
| CK / 1024
|-
| align="center" | 1
| align="center" | 1
| align="center" | 0
| Externer Pin 1, negative Flanke
|-
| align="center" | 1
| align="center" | 1
| align="center" | 1
| Externer Pin 1, positive Flanke
|}

Also um einen Takt von CK / 1024 zu generieren, verwenden wir
folgenden Befehl:

<syntaxhighlight lang="c">
TCCR1B = (1<<CS12) | (1<<CS10);
</syntaxhighlight>

Jetzt muss nur noch der Vergleichswert festgelegt werden. Diesen
schreiben wir in das 16-Bit Timer/Counter Output Compare Register '''OCR1A'''.

<syntaxhighlight lang="c">
OCR1A = xxx;
</syntaxhighlight>

Die folgende Grafik soll den Zusammenhang zwischen dem Vergleichswert und dem generierten '''PWM'''-Signal aufzeigen.

[[Image:PWM Theorie 3.gif]]

[[Image:PWM Theorie 4.gif]]

Ach ja, fast hätte ich's vergessen. Das generierte '''PWM'''-Signal
wird am Output Compare Pin '''OC1''' des Timers ausgegeben und leider können wir
deshalb auch beim AT90S2313 nur ein einzelnes '''PWM'''-Signal mit dieser Methode generieren. Andere AVR-Typen verfügen über bis zu vier PWM-Ausgänge. Zu beachten ist außerdem, das wenn der OC Pin aktiviert ist, er nichtmehr wie üblich funktioniert und z. B. nicht einfach über PINx ausgelesen werden kann.

Ein Programm, welches an einem ATmega8 den Fast-PWM Modus verwendet, den Modus 14, könnte so aussehen
<syntaxhighlight lang="c">
#include <avr/io.h>

int main()
{
// OC1A auf Ausgang
DDRB = (1 << PB1 ); //ATMega8
// DDRD = (1 << PD5 ); //ATMega16
//
// Timer 1 einstellen
//
// Modus 14:
// Fast PWM, Top von ICR1
//
// WGM13 WGM12 WGM11 WGM10
// 1 1 1 0
//
// Timer Vorteiler: 1
// CS12 CS11 CS10
// 0 0 1
//
// Steuerung des Ausgangsport: Set at BOTTOM, Clear at match
// COM1A1 COM1A0
// 1 0

TCCR1A = (1<<COM1A1) | (1<<WGM11);
TCCR1B = (1<<WGM13) | (1<<WGM12) | (1<<CS10);

// den Endwert (TOP) für den Zähler setzen
// der Zähler zählt bis zu diesem Wert

ICR1 = 0x6FFF;

// der Compare Wert
// Wenn der Zähler diesen Wert erreicht, wird mit
// obiger Konfiguration der OC1A Ausgang abgeschaltet
// Sobald der Zähler wieder bei 0 startet, wird der
// Ausgang wieder auf 1 gesetzt
//
// Durch Verändern dieses Wertes, werden die unterschiedlichen
// PWM Werte eingestellt.

OCR1A = 0x3FFF;

while (1) {}
}
</syntaxhighlight>

{| class="wikitable" style="text-align:center"
|+ '''PWM-Mode Tabelle aus dem Datenblatt des ATmega8515'''
|-
!Mode || WGM13 || WGM12 || WGM11 || WGM10 || Timer/Counter Mode of Operation
! TOP|| Update of OCR1x at || TOV1 Flag set on
|-
! 0
| 0
| 0
| 0
| 0
| Normal
| 0xFFFF
| Immediate
| MAX
|-
! 1
| 0
| 0
| 0
| 1
| PWM, Phase Correct, 8-Bit
| 0x00FF
| TOP
| BOTTOM
|-
! 2
| 0
| 0
| 1
| 0
| PWM, Phase Correct, 9-Bit
| 0x01FF
| TOP
| BOTTOM
|-
! 3
| 0
| 0
| 1
| 1
| PWM, Phase Correct, 10-Bit
| 0x03FF
| TOP
| BOTTOM
|-
! 4
| 0
| 1
| 0
| 0
| CTC
| OCR1A
| Immediate
| MAX
|-
! 5
| 0
| 1
| 0
| 1
| Fast PWM, 8-Bit
| 0x00FF
| BOTTOM
| TOP
|-
! 6
| 0
| 1
| 1
| 0
| Fast PWM, 9-Bit
| 0x01FF
| BOTTOM
| TOP
|-
! 7
| 0
| 1
| 1
| 1
| Fast PWM, 10-Bit
| 0x03FF
| BOTTOM
| TOP
|-
! 8
| 1
| 0
| 0
| 0
| PWM, Phase an Frequency Correct
| ICR1
| BOTTOM
| BOTTOM
|-
! 9
| 1
| 0
| 0
| 1
| PWM, Phase an Frequency Correct
| OCR1A
| BOTTOM
| BOTTOM
|-
! 10
| 1
| 0
| 1
| 0
| PWM, Phase Correct
| ICR1
| TOP
| BOTTOM
|-
! 11
| 1
| 0
| 1
| 1
| PWM, Phase an Frequency Correct
| OCR1A
| TOP
| BOTTOM
|-
! 12
| 1
| 1
| 0
| 0
| CTC
| ICR1
| Immediate
| MAX
|-
! 13
| 1
| 1
| 0
| 1
| Reserved
| -
| -
| -
|-
! 14
| 1
| 1
| 1
| 0
| Fast PWM
| ICR1
| BOTTOM
| TOP
|-
! 15
| 1
| 1
| 1
| 1
| Fast PWM
| OCR1A
| BOTTOM
| TOP
|}

Für Details der PWM-Möglichkeiten muss immer das jeweilige Datenblatt des Prozessors konsultiert werden, da sich die unterschiedlichen Prozessoren in ihren Möglichkeiten doch stark unterscheiden. Auch muss man aufpassen, welches zu setzende Bit in welchem Register ist. Auch hier kann es sein, dass gleichnamige Konfigurationsbits in unterschiedlichen Konfigurationsregistern (je nach konkretem Prozessortyp) sitzen.

== Anmerkungen ==
<references/>

[[Kategorie: Avr-gcc Tutorial]]

FIFO

2015-02-24T09:01:46Z

Kbuchegg: /* Beschreibung */

Ein FIFO (First-In-First-Out) ist ein Pufferspeicher nach dem "Warteschlangen-Prinzip". Pufferspeicher dienen dazu, für einen Prozessor Daten aufzufangen, die er noch nicht verarbeiten kann. Ein FIFO funktioniert definitionsgemäß so, dass das erste Element (First In), welches "hinten" in die Warteschlange eingefügt wird, später auch als erstes "vorne" herausgeholt wird (First Out). Das Gegenstück zum FIFO ist [[LIFO]].

Ein bekanntes Beispiel für einen FIFO-Speicher ist der des [[UART]]s im PC. Dieser sammelt ankommende Daten solange, bis er fast voll ist (meist 14 Bytes). Dann wird ein [[Interrupt]] ausgelöst und der Prozessor kann "auf einen Rutsch" alle Daten auf einmal auslesen. Ganz am Anfang hatten UARTs keinen FIFO und erzeugten für jedes empfangene Byte einen Interrupt, so wie es heute noch die meisten Mikrocontroller machen. Damit ist aber die CPU-Belastung wesentlich höher, was bei höheren Datenraten zu Problemen führen kann.

Die Umsetzung eines FIFOs in Software heißt Ringpuffer und weist auch eine feste Puffergröße auf. Wesentlicher Vorteil gegenüber der verketteten Liste ist die schnellere Ausführungszeit und der geringere Aufwand.

== Standard-Ringpuffer ==

Vorteile:
* Simpel
* Leicht verständlich
* Daten können auch vom Typ struct sein

Nachteile:
* Schnell aber nicht optimal

=== Beschreibung ===
{|
|-
|
[[Bild:Ringpuffer.png|300px]]
|
[[Bild:Circular buffer.png|200px]]
|}

Die Inhalte des Puffers werden in einem schlichten Array gespeichert und der Zugriff erfolgt über einen Integer-Index. Erreicht ein Index die Obergrenze springt dieser auf Null zurück. Topologisch ist dies äquivalent zu einem Ringschluss, bei dem man ja auch nach dem letzten Element wieder beim ersten angelangt ist. Man denke zb an das Zifferblatt einer Uhr, bei der nach der 59 wieder die 0 kommt. Ein größer-gleich statt nur eines ist-gleich Vergleichs ist sicherer gegenüber Programmfehlern, bei denen der Index verstellt wurde.
<syntaxhighlight lang="c">
write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
</syntaxhighlight>
Haben Lese- und Schreib-Index den gleichen Wert wird der Puffer als leer angesehen und es kann kein Element aus dem Puffer entnommen werden. Wenn write+1 und read identisch sind wird der Puffer als voll angesehen und es kann kein weiteres Element mehr im Puffer gespeichert werden. Nun fehlt noch der Sonderfall bei dem read gleich Null ist, hier funktioniert der write+1-Vergleich nicht mehr (wegen dem 'Überlauf' am Ende des Arrays, der den Ringschluss bewirkt) und die Abfrage einer zusätzlichen Bedingung ist zur Voll-Abfrage erforderlich.

<syntaxhighlight lang="c">
read == write => leer

write + 1 == read || read == 0 && write+1 == BUFFER_SIZE => voll
</syntaxhighlight>

Bei gleichzeitigem Zugriff zwischen dem Befüller (zb. einer UART-ISR) und dem Entnahmecode (zb. der Code in der Hauptschleife) muss ausgeschlossen werden, dass der Entnahmecode beim Lesen aus dem Puffer nicht durch den Interrupt unterbrochen werden kann. Denn während diese Funktion läuft ist zwischenzeitlich der read-Index in einem inkonsistenten Zustand. Erst nach Beendigung der Funktion spiegelt der read-Index wieder die Realität des Füllgrades wieder. Als Abhilfe dienen [[Interrupt#Atomarer_Datenzugriff|Atomare Abschnitte]], solche können durch keinen Interrupt unterbrochen werden. Die Radialkur deaktiviert alle Interrupts, besser ist die Deaktivierung eines einzelnen Interrupts. Es geht aber meistens auch so, da die FIFO Funktionen sehr kurz sind und daher auch die Interrupts nur kurz abgeschaltet werden. Im Allgemeinen werden versäumte Interrupts nach erneuter Aktivierung nachgeholt und gehen nicht verloren, so dass bereits anstehende Interrupts nur kurz verzögert werden. Solange die Interruptrate größer als die Ausführungsgeschwindigkeit der FIFO Funktionen ist, stellt das Abschalten der Interrupts daher auch in der Praxis meist kein allzugroßes Problem dar.

<syntaxhighlight lang="c">
cli()
ret = BufferOut(&var);
sei()
</syntaxhighlight>

Hilfreich ist die Initialisierung der Indizes (read, write) mit -1, denn damit kann man einen leere Ringpuffer von einem vollen unterscheiden. Initialisiert man nur mit 0, kann man einen leeren nicht von einem vollen mit read=write=0 unterscheiden.

Eine weitere Möglichkeit der Vereinfachung entsteht durch die Einführung einer "Counter" Variable, die den Füllstand des Buffers wiedergibt. Bei Einschreiben wird diese um +1 erhöht, beim Auslesen um 1 erniedrigt. Ist sie 0 ist der Buffer leer. Damit lässt sich die Codeeffizienz steigern, da die obigen Vergleiche kürzer ausfallen und sich auf nur diese eine Variable beschränken. Nachteilig ist allerdings, dass man eine weitere Variable im System hat und natürlich benötigen die entsprechenden Operationen zum Erhöhen bzw. Erniedrigen dieser Variable ja auch Ausführungszeit. Benötigt man im restlichen Code den Füllgrad der FIFO nicht als explizite Zahl, dann lohnt daher eine derartige Counter-Variable meistens nicht.

=== Code-Beispiel ===
<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 23

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
//if (buffer.write >= BUFFER_SIZE)
// buffer.write = 0; // erhöht sicherheit

if ( ( buffer.write + 1 == buffer.read ) ||
( buffer.read == 0 && buffer.write + 1 == BUFFER_SIZE ) )
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;

buffer.write++;
if (buffer.write >= BUFFER_SIZE)
buffer.write = 0;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read++;
if (buffer.read >= BUFFER_SIZE)
buffer.read = 0;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

== 2n-Ringpuffer - die schnellste Lösung ==

Vorteile:
* Durch Bitmaske auf den Feld-Index ''write'' kann der nicht "Amoklaufen" und beliebige Inhalte im Speicher überschreiben
* Sehr einfach, sehr schnell
Nachteile:
* Nur Größenfaktoren von 2n möglich
* Nur in speziellen Fällen Pointerreferenz möglich

=== Beschreibung ===

Wenn der Index am oberen Ende angekommen ist springt er an den Anfang zurück. Die Definition der Obergrenze wird nicht durch einen Vergleich realisiert, sondern durch Modulo-Arithmetik. Dies kann sehr einfach und schnell durch Maskieren des Index-Werts umgesetzt werden.

Beispiel:
<syntaxhighlight lang="c">
( write + 1 ) & MASK

15 = 0b00001111
15 + 1 = 16 = 0b000010000
16 & MASK = 0b000010000 & 0b000001111 = 0b000000000
</syntaxhighlight>

Daraus folgt das ''write'' nur einen Wert zwischen 0 und 15 einnehmen kann. Das ganze funktioniert nur mit Zahlen der Reihe 2n.

Da der Puffer nur eine endliche Größe aufweist, muss eine voll/leer Indikation verfügbar sein. read == write bedeutet Puffer leer, entsprechend bedeutet write + 1 == read, dass keine weiteren Elemente mehr hinzugefügt werden können, denn sonst würde das Hinzufügen weiterer Daten einen Pufferüberlauf hervorrufen. Für die Behandlung des Pufferüberlaufs gibt es zwei Methoden, nichts tun und Fehler zurück geben oder ältesten Puffer-Inhalt verwerfen (read+1).

<syntaxhighlight lang="c">
read == ((write + 1) & MASK)
</syntaxhighlight>

Auch hier verhindert die Bitmaske einen möglichen Überlauf. Weiter zu beachten ist, dass ein Byte durch die voll/leer Indikation verloren geht, der Puffer hat hier nur eine größe von 15 statt 16 Byte

Und noch ein kleiner Trick. Bei einer Zahl der Reihe 2^n lässt sich auf einfache Weise immer eine passende Bitmaske erzeugen und man sieht gleichzeitig klar die Anzahl der genutzten Bytes.

<syntaxhighlight lang="c">
# define SIZE 16
# define MASK (SIZE-1)

16 = 0b010000
16 - 1 = 0b001111
</syntaxhighlight>

Im Normalbetrieb sollte der Puffer nie voll ausgereizt sein und wenn der Puffer bereits überläuft ist es für die Systemstabilität und Fehleranlyse oft schon zu spät, denn von einem nicht mehr funktionierenden Gerät lässt sich nur wenig Information herauskitzeln. Da kann ein Frühwarnsystem mehr bieten, wobei zwei Ausprägungen typisch sind, Höchstwert merken und eine Meldeschwelle einführen.

<syntaxhighlight lang="c">
freeMemory = (read - write - 1 ) & MASK);
if (freeMemory < floodmark)
floodmark = freeMemory;
</syntaxhighlight>

<syntaxhighlight lang="c">
if ( (read - write - 1 ) & MASK) <= FLOODMARK;
FloodmarkExcess();
</syntaxhighlight>

Eine entsprechende Auswertung kann z.B. bei einer UART zur Steuerung des Handshakes benutzt werden, bei dem die Gegenstelle aufgefordert wird, das Senden kurzfristig einzustellen, damit man nicht Gefahr läuft, übertragene Zeichen zu verlieren, weil die FIFO voll wird. Dabei ist allerdings auch zu berücksichtigen, dass die Gegenstelle das Senden nicht sofort einstellen kann, da sich beispielsweise bereits Zeichen in der Sendehardware befinden können, die der Sender nicht mehr stoppen kann. Hier heißt es also rechtzeitig zu reagieren und nicht erst, wenn der FIFO propevoll ist. Fällt der Füllgrad einer darartigen UART-FIFO wieder unter eine gewisse Schwelle, dann wird der Gegenstelle signalisiert, dass sie mit dem Senden fortfahren kann.

=== Code-Beispiel ===

<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 16 // muss 2^n betragen (8, 16, 32, 64 ...)
#define BUFFER_MASK (BUFFER_SIZE-1) // Klammern auf keinen Fall vergessen

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
uint8_t next = ((buffer.write + 1) & BUFFER_MASK);

if (buffer.read == next)
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;
// buffer.data[buffer.write & BUFFER_MASK] = byte; // absolut Sicher
buffer.write = next;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read = (buffer.read+1) & BUFFER_MASK;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

=== FIFO mit C-Präprozessor ===

<syntaxhighlight lang="c">
#ifndef FIFO_H_
#define FIFO_H_

#include <stdint.h>

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[64];
} FIFO64_t;

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[128];
} FIFO128_t;

#define FIFO_init(fifo) { fifo._read = 0; fifo._write = 0; }

#define FIFO_available(fifo) ( fifo._read != fifo._write )

#define FIFO_read(fifo, size) ( \
(FIFO_available(fifo)) ? \
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
)

#define FIFO_write(fifo, data, size) { \
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
if(tmphead != fifo._read) { /* if buffer is not full */ \
fifo._write = tmphead; /* store new index */ \
fifo._buffer[tmphead] = data; /* store data in buffer */ \
} \
}

#define FIFO64_read(fifo) FIFO_read(fifo, 64)
#define FIFO64_write(fifo, data) FIFO_write(fifo, data, 64)

#define FIFO128_read(fifo) FIFO_read(fifo, 128)
#define FIFO128_write(fifo, data) FIFO_write(fifo, data, 128)

#endif /*FIFO_H_*/
</syntaxhighlight>

Hinweis: viele C-Compiler übersetzen automatisch eine Modulo-Division mit einem Divisor einer 2-er Potenz in Form einer entsprechenden Bitmaskierung. Zum einen erspart man sich dadurch das Bestimmen der entsprechenden Maske, zum anderen hat man dann den 'Bonus', dass der Code immer noch korrekt funktioniert (wenn auch langsamer), wenn der Anwender einen Fehler macht und die Array-Länge nicht als 2-er Potenz definiert. Die Operation

<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
</syntaxhighlight>
kann dann durch die in diesem Sinne gleichwertige Operation
<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) % size] : 0 \
</syntaxhighlight>
ausgedrückt werden, bzw.
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
</syntaxhighlight>
durch
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) % size); /* calculate buffer index */ \
</syntaxhighlight>

== Weblinks ==
* [http://en.wikipedia.org/wiki/Circular_buffer Circular buffer], englische Wikipedia

[[Kategorie:Grundlagen]]
[[Kategorie:Datenübertragung]]
[[Kategorie:Algorithmen und Arithmetik]]
[[Kategorie:Speicher und Dateisysteme]]

FIFO

2015-02-24T08:58:14Z

Kbuchegg: /* Beschreibung */

Ein FIFO (First-In-First-Out) ist ein Pufferspeicher nach dem "Warteschlangen-Prinzip". Pufferspeicher dienen dazu, für einen Prozessor Daten aufzufangen, die er noch nicht verarbeiten kann. Ein FIFO funktioniert definitionsgemäß so, dass das erste Element (First In), welches "hinten" in die Warteschlange eingefügt wird, später auch als erstes "vorne" herausgeholt wird (First Out). Das Gegenstück zum FIFO ist [[LIFO]].

Ein bekanntes Beispiel für einen FIFO-Speicher ist der des [[UART]]s im PC. Dieser sammelt ankommende Daten solange, bis er fast voll ist (meist 14 Bytes). Dann wird ein [[Interrupt]] ausgelöst und der Prozessor kann "auf einen Rutsch" alle Daten auf einmal auslesen. Ganz am Anfang hatten UARTs keinen FIFO und erzeugten für jedes empfangene Byte einen Interrupt, so wie es heute noch die meisten Mikrocontroller machen. Damit ist aber die CPU-Belastung wesentlich höher, was bei höheren Datenraten zu Problemen führen kann.

Die Umsetzung eines FIFOs in Software heißt Ringpuffer und weist auch eine feste Puffergröße auf. Wesentlicher Vorteil gegenüber der verketteten Liste ist die schnellere Ausführungszeit und der geringere Aufwand.

== Standard-Ringpuffer ==

Vorteile:
* Simpel
* Leicht verständlich
* Daten können auch vom Typ struct sein

Nachteile:
* Schnell aber nicht optimal

=== Beschreibung ===
{|
|-
|
[[Bild:Ringpuffer.png|300px]]
|
[[Bild:Circular buffer.png|200px]]
|}

Die Inhalte des Puffers werden in einem schlichten Array gespeichert und der Zugriff erfolgt über einen Integer-Index. Erreicht ein Index die Obergrenze springt dieser auf Null zurück. Topologisch ist dies äquivalent zu einem Ringschluss, bei dem man ja auch nach dem letzten Element wieder beim ersten angelangt ist. Man denke zb an das Zifferblatt einer Uhr, bei der nach der 59 wieder die 0 kommt. Ein größer-gleich statt nur eines ist-gleich Vergleichs ist sicherer gegenüber Programmfehlern, bei denen der Index verstellt wurde.
<syntaxhighlight lang="c">
write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
</syntaxhighlight>
Haben Lese- und Schreib-Index den gleichen Wert wird der Puffer als leer angesehen und es kann kein Element aus dem Puffer entnommen werden. Wenn write+1 und read identisch sind wird der Puffer als voll angesehen und es kann kein weiteres Element mehr im Puffer gespeichert werden. Nun fehlt noch der Sonderfall bei dem read gleich Null ist, hier funktioniert der write+1-Vergleich nicht mehr (wegen dem 'Überlauf' am Ende des Arrays, der den Ringschluss bewirkt) und die Abfrage einer zusätzlichen Bedingung ist zur Voll-Abfrage erforderlich.

<syntaxhighlight lang="c">
read == write => leer

write + 1 == read || read == 0 && write+1 == BUFFER_SIZE => voll
</syntaxhighlight>

Bei gleichzeitigem Zugriff zwischen dem Befüller (zb. einer UART-ISR) und dem Entnahmecode (zb. der Code in der Hauptschleife) muss ausgeschlossen werden, dass der Entnahmecode beim Lesen aus dem Puffer nicht durch den Interrupt unterbrochen werden kann. Denn während diese Funktion läuft ist zwischenzeitlich der read-Index in einem inkonsistenten Zustand. Erst nach Beendigung der Funktion spiegelt der read-Index wieder die Realität des Füllgrades wieder. Als Abhilfe dienen [[Interrupt#Atomarer_Datenzugriff|Atomare Abschnitte]], solche können durch keinen Interrupt unterbrochen werden. Die Radialkur deaktiviert alle Interrupts, besser ist die Deaktivierung eines einzelnen Interrupts. Es geht aber meistens auch so, da die FIFO Funktionen sehr kurz sind und daher auch die Interrupts nur kurz abgeschaltet werden. Im Allgemeinen werden versäumte Interrupts nach erneuter Aktivierung nachgeholt und gehen nicht verloren, so dass bereits anstehende Interrupts nur kurz verzögert werden. Solange die Interruptrate größer als die Ausführungsgeschwindigkeit der FIFO Funktionen ist, stellt das Abschalten der Interrupts daher auch in der Praxis meist kein allzugroßes Problem dar.

<syntaxhighlight lang="c">
cli()
ret = BufferOut(&var);
sei()
</syntaxhighlight>

Hilfreich ist die Initialisierung der Indizes (read, write) mit -1, denn damit kann man einen leere Ringpuffer von einem vollen unterscheiden. Initialisiert man nur mit 0, kann man einen leeren nicht von einem vollen mit read=write=0 unterscheiden.

Eine weitere Möglichkeit der Vereinfachung entsteht durch die Einführung einer "Counter" Variable, die den Füllstand des Buffers wiedergibt. Bei Einschreiben wird diese um +1 erhöht, beim Auslesen um 1 erniedrigt. Ist sie 0 ist der Buffer leer. Damit lässt sich die Codeeffizienz steigern, da die obigen Vergleiche kürzer ausfallen und sich auf nur diese eine Variable beschränken. Nachteilig ist allerdings, dass man eine weitere Variable im System hat und natürlich benötigen die entsprechenden Operationen zum Erhöhen bzw. Erniedrigen dieser Variable ja auch Ausführungszeit. Benötigt man im restlichen Code den Füllgrad der FIFO nicht als explizite Zahl, dann lohnt daher eine derartige Counter-Variable meistens nicht.

=== Code-Beispiel ===
<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 23

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
//if (buffer.write >= BUFFER_SIZE)
// buffer.write = 0; // erhöht sicherheit

if ( ( buffer.write + 1 == buffer.read ) ||
( buffer.read == 0 && buffer.write + 1 == BUFFER_SIZE ) )
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;

buffer.write++;
if (buffer.write >= BUFFER_SIZE)
buffer.write = 0;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read++;
if (buffer.read >= BUFFER_SIZE)
buffer.read = 0;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

== 2n-Ringpuffer - die schnellste Lösung ==

Vorteile:
* Durch Bitmaske auf den Feld-Index ''write'' kann der nicht "Amoklaufen" und beliebige Inhalte im Speicher überschreiben
* Sehr einfach, sehr schnell
Nachteile:
* Nur Größenfaktoren von 2n möglich
* Nur in speziellen Fällen Pointerreferenz möglich

=== Beschreibung ===

Wenn der Index am oberen Ende angekommen ist springt er an den Anfang zurück. Die Definition der Obergrenze wird nicht durch einen Vergleich realisiert, sondern durch Modulo-Arithmetik. Dies kann sehr einfach und schnell durch Maskieren des Index-Werts umgesetzt werden.

Beispiel:
<syntaxhighlight lang="c">
( write + 1 ) & MASK

15 = 0b00001111
15 + 1 = 16 = 0b000010000
16 & MASK = 0b000010000 & 0b000001111 = 0b000000000
</syntaxhighlight>

Daraus folgt das ''write'' nur einen Wert zwischen 0 und 15 einnehmen kann. Das ganze funktioniert nur mit Zahlen der Reihe 2n.

Da der Puffer nur eine endliche Größe aufweist, muss eine voll/leer Indikation verfügbar sein. read == write bedeutet Puffer leer, entsprechend bedeutet write + 1 == read, dass keine weiteren Elemente mehr hinzugefügt werden können, denn sonst würde das Hinzufügen weiterer Daten einen Pufferüberlauf hervorrufen. Für die Behandlung des Pufferüberlaufs gibt es zwei Methoden, nichts tun und Fehler zurück geben oder ältesten Puffer-Inhalt verwerfen (read+1).

<syntaxhighlight lang="c">
read == ((write + 1) & MASK)
</syntaxhighlight>

Auch hier verhindert die Bitmaske einen möglichen Überlauf. Weiter zu beachten ist, dass ein Byte durch die voll/leer Indikation verloren geht, der Puffer hat hier nur eine größe von 15 statt 16 Byte

Und noch ein kleiner Trick. Bei einer Zahl der Reihe 2^n lässt sich auf einfache Weise immer eine passende Bitmaske erzeugen und man sieht gleichzeitig klar die Anzahl der genutzten Bytes.

<syntaxhighlight lang="c">
# define SIZE 16
# define MASK (SIZE-1)

16 = 0b010000
16 - 1 = 0b001111
</syntaxhighlight>

Im Normalbetrieb sollte der Puffer nie voll ausgereizt sein und wenn der Puffer bereits überläuft ist es für die Systemstabilität und Fehleranlyse oft schon zu spät, denn von einem nicht mehr funktionierenden Gerät lässt sich nur wenig Information herauskitzeln. Da kann ein Frühwarnsystem mehr bieten, wobei zwei Ausprägungen typisch sind, Höchstwert merken und eine Meldeschwelle einführen.

<syntaxhighlight lang="c">
freeMemory = (read - write - 1 ) & MASK);
if (freeMemory < floodmark)
floodmark = freeMemory;
</syntaxhighlight>

<syntaxhighlight lang="c">
if ( (read - write - 1 ) & MASK) <= FLOODMARK;
FloodmarkExcess();
</syntaxhighlight>

Eine entsprechende Auswertung kann z.B. bei einer UART zur Steuerung des Handshakes benutzt werden, bei dem die Gegenstelle aufgefordert wird, das Senden kurzfristig einzustellen, damit man nicht Gefahr läuft, übertragene Zeichen zu verlieren. Fällt der Füllgrad einer darartigen UART-FIFO wieder unter eine gewisse Schwelle, dann wird der Gegenstelle signalisiert, dass sie mit dem Senden fortfahren kann.

=== Code-Beispiel ===

<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 16 // muss 2^n betragen (8, 16, 32, 64 ...)
#define BUFFER_MASK (BUFFER_SIZE-1) // Klammern auf keinen Fall vergessen

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
uint8_t next = ((buffer.write + 1) & BUFFER_MASK);

if (buffer.read == next)
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;
// buffer.data[buffer.write & BUFFER_MASK] = byte; // absolut Sicher
buffer.write = next;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read = (buffer.read+1) & BUFFER_MASK;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

=== FIFO mit C-Präprozessor ===

<syntaxhighlight lang="c">
#ifndef FIFO_H_
#define FIFO_H_

#include <stdint.h>

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[64];
} FIFO64_t;

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[128];
} FIFO128_t;

#define FIFO_init(fifo) { fifo._read = 0; fifo._write = 0; }

#define FIFO_available(fifo) ( fifo._read != fifo._write )

#define FIFO_read(fifo, size) ( \
(FIFO_available(fifo)) ? \
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
)

#define FIFO_write(fifo, data, size) { \
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
if(tmphead != fifo._read) { /* if buffer is not full */ \
fifo._write = tmphead; /* store new index */ \
fifo._buffer[tmphead] = data; /* store data in buffer */ \
} \
}

#define FIFO64_read(fifo) FIFO_read(fifo, 64)
#define FIFO64_write(fifo, data) FIFO_write(fifo, data, 64)

#define FIFO128_read(fifo) FIFO_read(fifo, 128)
#define FIFO128_write(fifo, data) FIFO_write(fifo, data, 128)

#endif /*FIFO_H_*/
</syntaxhighlight>

Hinweis: viele C-Compiler übersetzen automatisch eine Modulo-Division mit einem Divisor einer 2-er Potenz in Form einer entsprechenden Bitmaskierung. Zum einen erspart man sich dadurch das Bestimmen der entsprechenden Maske, zum anderen hat man dann den 'Bonus', dass der Code immer noch korrekt funktioniert (wenn auch langsamer), wenn der Anwender einen Fehler macht und die Array-Länge nicht als 2-er Potenz definiert. Die Operation

<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
</syntaxhighlight>
kann dann durch die in diesem Sinne gleichwertige Operation
<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) % size] : 0 \
</syntaxhighlight>
ausgedrückt werden, bzw.
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
</syntaxhighlight>
durch
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) % size); /* calculate buffer index */ \
</syntaxhighlight>

== Weblinks ==
* [http://en.wikipedia.org/wiki/Circular_buffer Circular buffer], englische Wikipedia

[[Kategorie:Grundlagen]]
[[Kategorie:Datenübertragung]]
[[Kategorie:Algorithmen und Arithmetik]]
[[Kategorie:Speicher und Dateisysteme]]

FIFO

2015-02-24T08:56:33Z

Kbuchegg: /* Beschreibung */

Ein FIFO (First-In-First-Out) ist ein Pufferspeicher nach dem "Warteschlangen-Prinzip". Pufferspeicher dienen dazu, für einen Prozessor Daten aufzufangen, die er noch nicht verarbeiten kann. Ein FIFO funktioniert definitionsgemäß so, dass das erste Element (First In), welches "hinten" in die Warteschlange eingefügt wird, später auch als erstes "vorne" herausgeholt wird (First Out). Das Gegenstück zum FIFO ist [[LIFO]].

Ein bekanntes Beispiel für einen FIFO-Speicher ist der des [[UART]]s im PC. Dieser sammelt ankommende Daten solange, bis er fast voll ist (meist 14 Bytes). Dann wird ein [[Interrupt]] ausgelöst und der Prozessor kann "auf einen Rutsch" alle Daten auf einmal auslesen. Ganz am Anfang hatten UARTs keinen FIFO und erzeugten für jedes empfangene Byte einen Interrupt, so wie es heute noch die meisten Mikrocontroller machen. Damit ist aber die CPU-Belastung wesentlich höher, was bei höheren Datenraten zu Problemen führen kann.

Die Umsetzung eines FIFOs in Software heißt Ringpuffer und weist auch eine feste Puffergröße auf. Wesentlicher Vorteil gegenüber der verketteten Liste ist die schnellere Ausführungszeit und der geringere Aufwand.

== Standard-Ringpuffer ==

Vorteile:
* Simpel
* Leicht verständlich
* Daten können auch vom Typ struct sein

Nachteile:
* Schnell aber nicht optimal

=== Beschreibung ===
{|
|-
|
[[Bild:Ringpuffer.png|300px]]
|
[[Bild:Circular buffer.png|200px]]
|}

Die Inhalte des Puffers werden in einem schlichten Array gespeichert und der Zugriff erfolgt über einen Integer-Index. Erreicht ein Index die Obergrenze springt dieser auf Null zurück. Topologisch ist dies äquivalent zu einem Ringschluss, bei dem man ja auch nach dem letzten Element wieder beim ersten angelangt ist. Man denke zb an das Zifferblatt einer Uhr, bei der nach der 59 wieder die 0 kommt. Ein größer-gleich statt nur eines ist-gleich Vergleichs ist sicherer gegenüber Programmfehlern, bei denen der Index verstellt wurde.
<syntaxhighlight lang="c">
write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
</syntaxhighlight>
Haben Lese- und Schreib-Index den gleichen Wert wird der Puffer als leer angesehen und es kann kein Element aus dem Puffer entnommen werden. Wenn write+1 und read identisch sind wird der Puffer als voll angesehen und es kann kein weiteres Element mehr im Puffer gespeichert werden. Nun fehlt noch der Sonderfall bei dem read gleich Null ist, hier funktioniert der write+1-Vergleich nicht mehr (wegen dem 'Überlauf' am Ende des Arrays, der den Ringschluss bewirkt) und die Abfrage einer zusätzlichen Bedingung ist zur Voll-Abfrage erforderlich.

<syntaxhighlight lang="c">
read == write => leer

write + 1 == read || read == 0 && write+1 == BUFFER_SIZE => voll
</syntaxhighlight>

Bei gleichzeitigem Zugriff zwischen dem Befüller (zb. einer UART-ISR) und dem Entnahmecode (zb. der Code in der Hauptschleife) muss ausgeschlossen werden, dass der Entnahmecode beim Lesen aus dem Puffer nicht durch den Interrupt unterbrochen werden kann. Denn während diese Funktion läuft ist zwischenzeitlich der read-Index in einem inkonsistenten Zustand. Erst nach Beendigung der Funktion spiegelt der read-Index wieder die Realität des Füllgrades wieder. Als Abhilfe dienen [[Interrupt#Atomarer_Datenzugriff|Atomare Abschnitte]], solche können durch keinen Interrupt unterbrochen werden. Die Radialkur deaktiviert alle Interrupts, besser ist die Deaktivierung eines einzelnen Interrupts. Es geht aber meistens auch so, da die FIFO Funktionen sehr kurz sind und daher auch die Interrupts nur kurz abgeschaltet werden. Im Allgemeinen werden versäumte Interrupts nach erneuter Aktivierung nachgeholt und gehen nicht verloren, so dass bereits anstehende Interrupts nur kurz verzögert werden. Solange die Interruptrate größer als die Ausführungsgeschwindigkeit der FIFO Funktionen ist, stellt das Abschalten der Interrupts daher auch in der Praxis meist kein allzugroßes Problem dar.

<syntaxhighlight lang="c">
cli()
ret = BufferOut(&var);
sei()
</syntaxhighlight>

Hilfreich ist die Initialisierung der Indizes (read, write) mit -1, denn damit kann man einen leere Ringpuffer von einem vollen unterscheiden. Initialisiert man nur mit 0, kann man einen leeren nicht von einem vollen mit read=write=0 unterscheiden.

Eine weitere Möglichkeit der Vereinfachung entsteht durch die Einführung einer "Counter" Variable, die den Füllstand des Buffers wiedergibt. Bei Einschreiben wird diese um +1 erhöht, beim Auslesen um 1 erniedrigt. Ist sie 0 ist der Buffer leer. Damit lässt sich die Codeeffizienz steigern, da die obigen Vergleiche kürzer ausfallen und sich auf nur diese eine Variable beschränken. Nachteilig ist allerdings, dass man eine weitere Variable im System hat und natürlich benötigen die entsprechenden Operationen zum Erhöhen bzw. Erniedrigen dieser Variable ja auch Ausführungszeit. Benötigt man im restlichen Code den Füllgrad der FIFO nicht als explizite Zahl, dann lohnt daher eine derartige Counter-Variable meistens nicht.

=== Code-Beispiel ===
<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 23

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
//if (buffer.write >= BUFFER_SIZE)
// buffer.write = 0; // erhöht sicherheit

if ( ( buffer.write + 1 == buffer.read ) ||
( buffer.read == 0 && buffer.write + 1 == BUFFER_SIZE ) )
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;

buffer.write++;
if (buffer.write >= BUFFER_SIZE)
buffer.write = 0;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read++;
if (buffer.read >= BUFFER_SIZE)
buffer.read = 0;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

== 2n-Ringpuffer - die schnellste Lösung ==

Vorteile:
* Durch Bitmaske auf den Feld-Index ''write'' kann der nicht "Amoklaufen" und beliebige Inhalte im Speicher überschreiben
* Sehr einfach, sehr schnell
Nachteile:
* Nur Größenfaktoren von 2n möglich
* Nur in speziellen Fällen Pointerreferenz möglich

=== Beschreibung ===

Wenn der Index am oberen Ende angekommen ist springt er an den Anfang zurück. Die Definition der Obergrenze wird nicht durch einen Vergleich realisiert, sondern durch Modulo-Arithmetik. Dies kann sehr einfach und schnell durch Maskieren des Index-Werts umgesetzt werden.

Beispiel:
<syntaxhighlight lang="c">
( write + 1 ) & MASK

15 = 0b00001111
15 + 1 = 16 = 0b000010000
16 & MASK = 0b000010000 & 0b000001111 = 0b000000000
</syntaxhighlight>

Daraus folgt das ''write'' nur einen Wert zwischen 0 und 15 einnehmen kann. Das ganze funktioniert nur mit Zahlen der Reihe 2n.

Da der Puffer nur eine endliche Größe aufweist, muss eine voll/leer Indikation verfügbar sein. read == write bedeutet Puffer leer, entsprechend bedeutet write + 1 == read, dass keine weiteren Elemente mehr hinzugefügt werden können, denn sonst würde das Hinzufügen weiterer Daten einen Pufferüberlauf hervorrufen. Für die Behandlung des Pufferüberlaufs gibt es zwei Methoden, nichts tun und Fehler zurück geben oder ältesten Puffer-Inhalt verwerfen (read+1).

<syntaxhighlight lang="c">
read == ((write + 1) & MASK)
</syntaxhighlight>

Auch hier verhindert die Bitmaske einen möglichen Überlauf. Weiter zu beachten ist, dass ein Byte durch die voll/leer Indikation verloren geht, der Puffer hat hier nur eine größe von 15 statt 16 Byte

Und noch ein kleiner Trick. Bei einer Zahl der Reihe 2^n lässt sich auf einfache Weise immer eine passende Bitmaske erzeugen und man sieht gleichzeitig klar die Anzahl der genutzten Bytes.

<syntaxhighlight lang="c">
# define SIZE 16
# define MASK (SIZE-1)

16 = 0b010000
16 - 1 = 0b001111
</syntaxhighlight>

Im Normalbetrieb sollte der Puffer nie voll ausgereizt sein und wenn der Puffer bereits überläuft ist es für die Systemstabilität und Fehleranlyse oft schon zu spät, denn von einem nicht mehr funktionierenden Gerät lässt sich nur wenig Information herauskitzeln. Da kann ein Frühwarnsystem mehr bieten, wobei zwei Ausprägungen typisch sind, Höchstwert merken und eine Meldeschwelle einführen.

<syntaxhighlight lang="c">
freeMemory = (read - write - 1 ) & MASK);
if (freeMemory < floodmark)
floodmark = freeMemory;
</syntaxhighlight>

Eine entsprechende Auswertung kann z.B. bei einer UART zur Steuerung des Handshakes benutzt werden, bei dem die Gegenstelle aufgefordert wird, das Senden kurzfristig einzustellen, damit man nicht Gefahr läuft, übertragene Zeichen zu verlieren. Fällt der Füllgrad einer darartigen UART-FIFO wieder unter eine gewisse Schwelle, dann wird der Gegenstelle signalisiert, dass sie mit dem Senden fortfahren kann.

<syntaxhighlight lang="c">
if ( (read - write - 1 ) & MASK) <= FLOODMARK;
FloodmarkExcess();
</syntaxhighlight>

=== Code-Beispiel ===

<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 16 // muss 2^n betragen (8, 16, 32, 64 ...)
#define BUFFER_MASK (BUFFER_SIZE-1) // Klammern auf keinen Fall vergessen

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
uint8_t next = ((buffer.write + 1) & BUFFER_MASK);

if (buffer.read == next)
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;
// buffer.data[buffer.write & BUFFER_MASK] = byte; // absolut Sicher
buffer.write = next;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read = (buffer.read+1) & BUFFER_MASK;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

=== FIFO mit C-Präprozessor ===

<syntaxhighlight lang="c">
#ifndef FIFO_H_
#define FIFO_H_

#include <stdint.h>

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[64];
} FIFO64_t;

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[128];
} FIFO128_t;

#define FIFO_init(fifo) { fifo._read = 0; fifo._write = 0; }

#define FIFO_available(fifo) ( fifo._read != fifo._write )

#define FIFO_read(fifo, size) ( \
(FIFO_available(fifo)) ? \
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
)

#define FIFO_write(fifo, data, size) { \
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
if(tmphead != fifo._read) { /* if buffer is not full */ \
fifo._write = tmphead; /* store new index */ \
fifo._buffer[tmphead] = data; /* store data in buffer */ \
} \
}

#define FIFO64_read(fifo) FIFO_read(fifo, 64)
#define FIFO64_write(fifo, data) FIFO_write(fifo, data, 64)

#define FIFO128_read(fifo) FIFO_read(fifo, 128)
#define FIFO128_write(fifo, data) FIFO_write(fifo, data, 128)

#endif /*FIFO_H_*/
</syntaxhighlight>

Hinweis: viele C-Compiler übersetzen automatisch eine Modulo-Division mit einem Divisor einer 2-er Potenz in Form einer entsprechenden Bitmaskierung. Zum einen erspart man sich dadurch das Bestimmen der entsprechenden Maske, zum anderen hat man dann den 'Bonus', dass der Code immer noch korrekt funktioniert (wenn auch langsamer), wenn der Anwender einen Fehler macht und die Array-Länge nicht als 2-er Potenz definiert. Die Operation

<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
</syntaxhighlight>
kann dann durch die in diesem Sinne gleichwertige Operation
<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) % size] : 0 \
</syntaxhighlight>
ausgedrückt werden, bzw.
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
</syntaxhighlight>
durch
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) % size); /* calculate buffer index */ \
</syntaxhighlight>

== Weblinks ==
* [http://en.wikipedia.org/wiki/Circular_buffer Circular buffer], englische Wikipedia

[[Kategorie:Grundlagen]]
[[Kategorie:Datenübertragung]]
[[Kategorie:Algorithmen und Arithmetik]]
[[Kategorie:Speicher und Dateisysteme]]

FIFO

2015-02-24T08:52:30Z

Kbuchegg: Code kommentiert, fehlende Makros ergänzt.

Ein FIFO (First-In-First-Out) ist ein Pufferspeicher nach dem "Warteschlangen-Prinzip". Pufferspeicher dienen dazu, für einen Prozessor Daten aufzufangen, die er noch nicht verarbeiten kann. Ein FIFO funktioniert definitionsgemäß so, dass das erste Element (First In), welches "hinten" in die Warteschlange eingefügt wird, später auch als erstes "vorne" herausgeholt wird (First Out). Das Gegenstück zum FIFO ist [[LIFO]].

Ein bekanntes Beispiel für einen FIFO-Speicher ist der des [[UART]]s im PC. Dieser sammelt ankommende Daten solange, bis er fast voll ist (meist 14 Bytes). Dann wird ein [[Interrupt]] ausgelöst und der Prozessor kann "auf einen Rutsch" alle Daten auf einmal auslesen. Ganz am Anfang hatten UARTs keinen FIFO und erzeugten für jedes empfangene Byte einen Interrupt, so wie es heute noch die meisten Mikrocontroller machen. Damit ist aber die CPU-Belastung wesentlich höher, was bei höheren Datenraten zu Problemen führen kann.

Die Umsetzung eines FIFOs in Software heißt Ringpuffer und weist auch eine feste Puffergröße auf. Wesentlicher Vorteil gegenüber der verketteten Liste ist die schnellere Ausführungszeit und der geringere Aufwand.

== Standard-Ringpuffer ==

Vorteile:
* Simpel
* Leicht verständlich
* Daten können auch vom Typ struct sein

Nachteile:
* Schnell aber nicht optimal

=== Beschreibung ===
{|
|-
|
[[Bild:Ringpuffer.png|300px]]
|
[[Bild:Circular buffer.png|200px]]
|}

Die Inhalte des Puffers werden in einem schlichten Array gespeichert und der Zugriff erfolgt über einen Integer-Index. Erreicht ein Index die Obergrenze springt dieser auf Null zurück. Topologisch ist dies äquivalent zu einem Ringschluss, bei dem man ja auch nach dem letzten Element wieder beim ersten angelangt ist. Man denke zb an das Zifferblatt einer Uhr, bei der nach der 59 wieder die 0 kommt. Ein größer-gleich statt nur eines ist-gleich Vergleichs ist sicherer gegenüber Programmfehlern, bei denen der Index verstellt wurde.
<syntaxhighlight lang="c">
write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
</syntaxhighlight>
Haben Lese- und Schreib-Index den gleichen Wert wird der Puffer als leer angesehen und es kann kein Element aus dem Puffer entnommen werden. Wenn write+1 und read identisch sind wird der Puffer als voll angesehen und es kann kein weiteres Element mehr im Puffer gespeichert werden. Nun fehlt noch der Sonderfall bei dem read gleich Null ist, hier funktioniert der write+1-Vergleich nicht mehr (wegen dem 'Überlauf' am Ende des Arrays, der den Ringschluss bewirkt) und die Abfrage einer zusätzlichen Bedingung ist zur Voll-Abfrage erforderlich.

<syntaxhighlight lang="c">
read == write => leer

write + 1 == read || read == 0 && write+1 == BUFFER_SIZE => voll
</syntaxhighlight>

Bei gleichzeitigem Zugriff zwischen dem Befüller (zb. einer UART-ISR) und dem Entnahmecode (zb. der Code in der Hauptschleife) muss ausgeschlossen werden, dass der Entnahmecode beim Lesen aus dem Puffer nicht durch den Interrupt unterbrochen werden kann. Denn während diese Funktion läuft ist zwischenzeitlich der read-Index in einem inkonsistenten Zustand. Erst nach Beendigung der Funktion spiegelt der read-Index wieder die Realität des Füllgrades wieder. Als Abhilfe dienen [[Interrupt#Atomarer_Datenzugriff|Atomare Abschnitte]], solche können durch keinen Interrupt unterbrochen werden. Die Radialkur deaktiviert alle Interrupts, besser ist die Deaktivierung eines einzelnen Interrupts. Es geht aber meistens auch so, da die FIFO Funktionen sehr kurz sind und daher auch die Interrupts nur kurz abgeschaltet werden. Im Allgemeinen werden versäumte Interrupts nach erneuter Aktivierung nachgeholt und gehen nicht verloren, so dass bereits anstehende Interrupts nur kurz verzögert werden. Solange die Interruptrate größer als die Ausführungsgeschwindigkeit der FIFO Funktionen ist, stellt das Abschalten der Interrupts daher auch in der Praxis meist kein allzugroßes Problem dar.

<syntaxhighlight lang="c">
cli()
ret = BufferOut(&var);
sei()
</syntaxhighlight>

Hilfreich ist die Initialisierung der Indizes (read, write) mit -1, denn damit kann man einen leere Ringpuffer von einem vollen unterscheiden. Initialisiert man nur mit 0, kann man einen leeren nicht von einem vollen mit read=write=0 unterscheiden.

Eine weitere Möglichkeit der Vereinfachung entsteht durch die Einführung einer "Counter" Variable, die den Füllstand des Buffers wiedergibt. Bei Einschreiben wird diese um +1 erhöht, beim Auslesen um 1 erniedrigt. Ist sie 0 ist der Buffer leer. Damit lässt sich die Codeeffizienz steigern, da die obigen Vergleiche kürzer ausfallen und sich auf nur diese eine Variable beschränken. Nachteilig ist allerdings, dass man eine weitere Variable im System hat und natürlich benötigen die entsprechenden Operationen zum Erhöhen bzw. Erniedrigen dieser Variable ja auch Ausführungszeit. Benötigt man im restlichen Code den Füllgrad der FIFO nicht als explizite Zahl, dann lohnt daher eine derartige Counter-Variable meistens nicht.

=== Code-Beispiel ===
<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 23

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
//if (buffer.write >= BUFFER_SIZE)
// buffer.write = 0; // erhöht sicherheit

if ( ( buffer.write + 1 == buffer.read ) ||
( buffer.read == 0 && buffer.write + 1 == BUFFER_SIZE ) )
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;

buffer.write++;
if (buffer.write >= BUFFER_SIZE)
buffer.write = 0;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read++;
if (buffer.read >= BUFFER_SIZE)
buffer.read = 0;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

== 2n-Ringpuffer - die schnellste Lösung ==

Vorteile:
* Durch Bitmaske auf den Feld-Index ''write'' kann der nicht "Amoklaufen" und beliebige Inhalte im Speicher überschreiben
* Sehr einfach, sehr schnell
Nachteile:
* Nur Größenfaktoren von 2n möglich
* Nur in speziellen Fällen Pointerreferenz möglich

=== Beschreibung ===

Wenn der Index am oberen Ende angekommen ist springt er an den Anfang zurück. Die Definition der Obergrenze wird nicht durch einen Vergleich realisiert, sondern durch Modulo-Arithmetik. Dies kann sehr einfach und schnell durch Maskieren des Index-Werts umgesetzt werden.

Beispiel:
<syntaxhighlight lang="c">
( write + 1 ) & MASK

15 = 0b00001111
15 + 1 = 16 = 0b000010000
16 & MASK = 0b000010000 & 0b000001111 = 0b000000000
</syntaxhighlight>

Daraus folgt das ''write'' nur einen Wert zwischen 0 und 15 einnehmen kann. Das ganze funktioniert nur mit Zahlen der Reihe 2n.

Da der Puffer nur eine endliche Größe aufweist, muss eine voll/leer Indikation verfügbar sein. read == write bedeutet Puffer leer, entsprechend bedeutet write + 1 == read, dass keine weiteren Elemente mehr hinzugefügt werden können, denn sonst würde das Hinzufügen weiterer Daten einen Pufferüberlauf hervorrufen. Für die Behandlung des Pufferüberlaufs gibt es zwei Methoden, nichts tun und Fehler zurück geben oder ältesten Puffer-Inhalt verwerfen (read+1).

<syntaxhighlight lang="c">
read == ((write + 1) & MASK)
</syntaxhighlight>

Auch hier verhindert die Bitmaske einen möglichen Überlauf. Weiter zu beachten ist, dass ein Byte durch die voll/leer Indikation verloren geht, der Puffer hat hier nur eine größe von 15 statt 16 Byte

Und noch ein kleiner Trick. Bei einer Zahl der Reihe 2^n lässt sich auf einfache Weise immer eine passende Bitmaske erzeugen und man sieht gleichzeitig klar die Anzahl der genutzten Bytes.

<syntaxhighlight lang="c">
# define SIZE 16
# define MASK (SIZE-1)

16 = 0b010000
16 - 1 = 0b001111
</syntaxhighlight>

Im Normalbetrieb sollte der Puffer nie voll ausgereizt sein und wenn der Puffer bereits überläuft ist es für die Systemstabilität und Fehleranlyse oft schon zu spät, denn von einem nicht mehr funktionierenden Gerät lässt sich nur wenig Information herauskitzeln. Da kann ein Frühwarnsystem mehr bieten, wobei zwei Ausprägungen typisch sind, Höchstwert merken und eine Meldeschwelle einführen.

<syntaxhighlight lang="c">
freeMemory = (read - write - 1 ) & MASK);
if (freeMemory < floodmark)
floodmark = freeMemory;
</syntaxhighlight>

<syntaxhighlight lang="c">
if ( (read - write - 1 ) & MASK) <= FLOODMARK;
FloodmarkExcess();
</syntaxhighlight>

=== Code-Beispiel ===

<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 16 // muss 2^n betragen (8, 16, 32, 64 ...)
#define BUFFER_MASK (BUFFER_SIZE-1) // Klammern auf keinen Fall vergessen

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
uint8_t next = ((buffer.write + 1) & BUFFER_MASK);

if (buffer.read == next)
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;
// buffer.data[buffer.write & BUFFER_MASK] = byte; // absolut Sicher
buffer.write = next;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read = (buffer.read+1) & BUFFER_MASK;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

=== FIFO mit C-Präprozessor ===

<syntaxhighlight lang="c">
#ifndef FIFO_H_
#define FIFO_H_

#include <stdint.h>

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[64];
} FIFO64_t;

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[128];
} FIFO128_t;

#define FIFO_init(fifo) { fifo._read = 0; fifo._write = 0; }

#define FIFO_available(fifo) ( fifo._read != fifo._write )

#define FIFO_read(fifo, size) ( \
(FIFO_available(fifo)) ? \
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
)

#define FIFO_write(fifo, data, size) { \
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
if(tmphead != fifo._read) { /* if buffer is not full */ \
fifo._write = tmphead; /* store new index */ \
fifo._buffer[tmphead] = data; /* store data in buffer */ \
} \
}

#define FIFO64_read(fifo) FIFO_read(fifo, 64)
#define FIFO64_write(fifo, data) FIFO_write(fifo, data, 64)

#define FIFO128_read(fifo) FIFO_read(fifo, 128)
#define FIFO128_write(fifo, data) FIFO_write(fifo, data, 128)

#endif /*FIFO_H_*/
</syntaxhighlight>

Hinweis: viele C-Compiler übersetzen automatisch eine Modulo-Division mit einem Divisor einer 2-er Potenz in Form einer entsprechenden Bitmaskierung. Zum einen erspart man sich dadurch das Bestimmen der entsprechenden Maske, zum anderen hat man dann den 'Bonus', dass der Code immer noch korrekt funktioniert (wenn auch langsamer), wenn der Anwender einen Fehler macht und die Array-Länge nicht als 2-er Potenz definiert. Die Operation

<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
</syntaxhighlight>
kann dann durch die in diesem Sinne gleichwertige Operation
<syntaxhighlight lang="c">
fifo._buffer[fifo._read = (fifo._read + 1) % size] : 0 \
</syntaxhighlight>
ausgedrückt werden, bzw.
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
</syntaxhighlight>
durch
<syntaxhighlight lang="c">
uint8_t tmphead = ( fifo._write + 1 ) % size); /* calculate buffer index */ \
</syntaxhighlight>

== Weblinks ==
* [http://en.wikipedia.org/wiki/Circular_buffer Circular buffer], englische Wikipedia

[[Kategorie:Grundlagen]]
[[Kategorie:Datenübertragung]]
[[Kategorie:Algorithmen und Arithmetik]]
[[Kategorie:Speicher und Dateisysteme]]

FIFO

2015-02-24T08:34:03Z

Kbuchegg: Kommentiert, fehlende Makros für die Return Werte eingefügt.

Ein FIFO (First-In-First-Out) ist ein Pufferspeicher nach dem "Warteschlangen-Prinzip". Pufferspeicher dienen dazu, für einen Prozessor Daten aufzufangen, die er noch nicht verarbeiten kann. Ein FIFO funktioniert definitionsgemäß so, dass das erste Element (First In), welches "hinten" in die Warteschlange eingefügt wird, später auch als erstes "vorne" herausgeholt wird (First Out). Das Gegenstück zum FIFO ist [[LIFO]].

Ein bekanntes Beispiel für einen FIFO-Speicher ist der des [[UART]]s im PC. Dieser sammelt ankommende Daten solange, bis er fast voll ist (meist 14 Bytes). Dann wird ein [[Interrupt]] ausgelöst und der Prozessor kann "auf einen Rutsch" alle Daten auf einmal auslesen. Ganz am Anfang hatten UARTs keinen FIFO und erzeugten für jedes empfangene Byte einen Interrupt, so wie es heute noch die meisten Mikrocontroller machen. Damit ist aber die CPU-Belastung wesentlich höher, was bei höheren Datenraten zu Problemen führen kann.

Die Umsetzung eines FIFOs in Software heißt Ringpuffer und weist auch eine feste Puffergröße auf. Wesentlicher Vorteil gegenüber der verketteten Liste ist die schnellere Ausführungszeit und der geringere Aufwand.

== Standard-Ringpuffer ==

Vorteile:
* Simpel
* Leicht verständlich
* Daten können auch vom Typ struct sein

Nachteile:
* Schnell aber nicht optimal

=== Beschreibung ===
{|
|-
|
[[Bild:Ringpuffer.png|300px]]
|
[[Bild:Circular buffer.png|200px]]
|}

Die Inhalte des Puffers werden in einem schlichten Array gespeichert und der Zugriff erfolgt über einen Integer-Index. Erreicht ein Index die Obergrenze springt dieser auf Null zurück. Topologisch ist dies äquivalent zu einem Ringschluss, bei dem man ja auch nach dem letzten Element wieder beim ersten angelangt ist. Man denke zb an das Zifferblatt einer Uhr, bei der nach der 59 wieder die 0 kommt. Ein größer-gleich statt nur eines ist-gleich Vergleichs ist sicherer gegenüber Programmfehlern, bei denen der Index verstellt wurde.
<syntaxhighlight lang="c">
write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
</syntaxhighlight>
Haben Lese- und Schreib-Index den gleichen Wert wird der Puffer als leer angesehen und es kann kein Element aus dem Puffer entnommen werden. Wenn write+1 und read identisch sind wird der Puffer als voll angesehen und es kann kein weiteres Element mehr im Puffer gespeichert werden. Nun fehlt noch der Sonderfall bei dem read gleich Null ist, hier funktioniert der write+1-Vergleich nicht mehr (wegen dem 'Überlauf' am Ende des Arrays, der den Ringschluss bewirkt) und die Abfrage einer zusätzlichen Bedingung ist zur Voll-Abfrage erforderlich.

<syntaxhighlight lang="c">
read == write => leer

write + 1 == read || read == 0 && write+1 == BUFFER_SIZE => voll
</syntaxhighlight>

Bei gleichzeitigem Zugriff zwischen dem Befüller (zb. einer UART-ISR) und dem Entnahmecode (zb. der Code in der Hauptschleife) muss ausgeschlossen werden, dass der Entnahmecode beim Lesen aus dem Puffer nicht durch den Interrupt unterbrochen werden kann. Denn während diese Funktion läuft ist zwischenzeitlich der read-Index in einem inkonsistenten Zustand. Erst nach Beendigung der Funktion spiegelt der read-Index wieder die Realität des Füllgrades wieder. Als Abhilfe dienen [[Interrupt#Atomarer_Datenzugriff|Atomare Abschnitte]], solche können durch keinen Interrupt unterbrochen werden. Die Radialkur deaktiviert alle Interrupts, besser ist die Deaktivierung eines einzelnen Interrupts. Es geht aber meistens auch so, da die FIFO Funktionen sehr kurz sind und daher auch die Interrupts nur kurz abgeschaltet werden. Im Allgemeinen werden versäumte Interrupts nach erneuter Aktivierung nachgeholt und gehen nicht verloren, so dass bereits anstehende Interrupts nur kurz verzögert werden. Solange die Interruptrate größer als die Ausführungsgeschwindigkeit der FIFO Funktionen ist, stellt das Abschalten der Interrupts daher auch in der Praxis meist kein allzugroßes Problem dar.

<syntaxhighlight lang="c">
cli()
ret = BufferOut(&var);
sei()
</syntaxhighlight>

Hilfreich ist die Initialisierung der Indizes (read, write) mit -1, denn damit kann man einen leere Ringpuffer von einem vollen unterscheiden. Initialisiert man nur mit 0, kann man einen leeren nicht von einem vollen mit read=write=0 unterscheiden.

Eine weitere Möglichkeit der Vereinfachung entsteht durch die Einführung einer "Counter" Variable, die den Füllstand des Buffers wiedergibt. Bei Einschreiben wird diese um +1 erhöht, beim Auslesen um 1 erniedrigt. Ist sie 0 ist der Buffer leer. Damit lässt sich die Codeeffizienz steigern, da die obigen Vergleiche kürzer ausfallen und sich auf nur diese eine Variable beschränken. Nachteilig ist allerdings, dass man eine weitere Variable im System hat und natürlich benötigen die entsprechenden Operationen zum Erhöhen bzw. Erniedrigen dieser Variable ja auch Ausführungszeit. Benötigt man im restlichen Code den Füllgrad der FIFO nicht als explizite Zahl, dann lohnt daher eine derartige Counter-Variable meistens nicht.

=== Code-Beispiel ===
<syntaxhighlight lang="c">

#define BUFFER_FAIL 0
#define BUFFER_SUCCESS 1

#define BUFFER_SIZE 23

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

//
// Stellt 1 Byte in den Ringbuffer
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist voll. Es kann kein weiteres Byte gespeichert werden
// BUFFER_SUCCESS das Byte wurde gespeichert
//
uint8_t BufferIn(uint8_t byte)
{
//if (buffer.write >= BUFFER_SIZE)
// buffer.write = 0; // erhöht sicherheit

if ( ( buffer.write + 1 == buffer.read ) ||
( buffer.read == 0 && buffer.write + 1 == BUFFER_SIZE ) )
return BUFFER_FAIL; // voll

buffer.data[buffer.write] = byte;

buffer.write++;
if (buffer.write >= BUFFER_SIZE)
buffer.write = 0;

return BUFFER_SUCCESS;
}

//
// Holt 1 Byte aus dem Ringbuffer, sofern mindestens eines abholbereit ist
//
// Returns:
// BUFFER_FAIL der Ringbuffer ist leer. Es kann kein Byte geliefert werden.
// BUFFER_SUCCESS 1 Byte wurde geliefert
//
uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return BUFFER_FAIL;

*pByte = buffer.data[buffer.read];

buffer.read++;
if (buffer.read >= BUFFER_SIZE)
buffer.read = 0;

return BUFFER_SUCCESS;
}
</syntaxhighlight>

== 2n-Ringpuffer - die schnellste Lösung ==

Vorteile:
* Durch Bitmaske auf den Feld-Index ''write'' kann der nicht "Amoklaufen" und beliebige Inhalte im Speicher überschreiben
* Sehr einfach, sehr schnell
* Daten können auch vom Typ ''struct'' sein
Nachteile:
* Nur Größenfaktoren von 2n möglich
* Nur in speziellen Fällen Pointerreferenz möglich

=== Beschreibung ===

Wenn der Index am oberen Ende angekommen ist springt er an den Anfang zurück. Die Definition der Obergrenze wird nicht durch einen Vergleich realisiert, sondern durch Modulo-Arithmetik. Dies kann sehr einfach und schnell durch Maskieren des Index-Werts umgesetzt werden.

Beispiel:
<syntaxhighlight lang="c">
( write + 1 ) & MASK

15 = 0b00001111
15 + 1 = 16 = 0b000010000
16 & MASK = 0b000010000 & 0b000001111 = 0b000000000
</syntaxhighlight>

Daraus folgt das ''write'' nur einen Wert zwischen 0 und 15 einnehmen kann. Das ganze funktioniert nur mit Zahlen der Reihe 2n.

Da der Puffer nur eine endliche Größe aufweist, muss eine voll/leer Indikation verfügbar sein. read == write bedeutet Puffer leer, entsprechend bedeutet write + 1 == read, dass keine weiteren Elemente mehr hinzugefügt werden können, denn sonst würde das Hinzufügen weiterer Daten einen Pufferüberlauf hervorrufen. Für die Behandlung des Pufferüberlaufs gibt es zwei Methoden, nichts tun und Fehler zurück geben oder ältesten Puffer-Inhalt verwerfen (read+1).

<syntaxhighlight lang="c">
read == ((write + 1) & MASK)
</syntaxhighlight>

Auch hier verhindert die Bitmaske einen möglichen Überlauf. Weiter zu beachten ist, dass ein Byte durch die voll/leer Indikation verloren geht, der Puffer hat hier nur eine größe von 15 statt 16 Byte

Und noch ein kleiner Trick. Bei einer Zahl der Reihe 2^n lässt sich auf einfache Weise immer eine passende Bitmaske erzeugen und man sieht gleichzeitig klar die Anzahl der genutzten Bytes.

<syntaxhighlight lang="c">
# define SIZE 16
# define MASK (SIZE-1)

16 = 0b010000
16 - 1 = 0b001111
</syntaxhighlight>

Im Normalbetrieb sollte der Puffer nie voll ausgereizt sein und wenn der Puffer bereits überläuft ist es für die Systemstabilität und Fehleranlyse oft schon zu spät, denn von einem nicht mehr funktionierenden Gerät lässt sich nur wenig Information herauskitzeln. Da kann ein Frühwarnsystem mehr bieten, wobei zwei Ausprägungen typisch sind, Höchstwert merken und eine Meldeschwelle einführen.

<syntaxhighlight lang="c">
freeMemory = (read - write - 1 ) & MASK);
if (freeMemory < floodmark)
floodmark = freeMemory;
</syntaxhighlight>

<syntaxhighlight lang="c">
if ( (read - write - 1 ) & MASK) <= FLOODMARK;
FloodmarkExcess();
</syntaxhighlight>

=== Code-Beispiel ===

<syntaxhighlight lang="c">
#define BUFFER_SIZE 16 // muss 2^n betragen (8, 16, 32, 64 ...)
#define BUFFER_MASK (BUFFER_SIZE-1) // Klammern auf keinen Fall vergessen

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

uint8_t BufferIn(uint8_t byte)
{
uint8_t next = ((buffer.write + 1) & BUFFER_MASK);
if (buffer.read == next)
return FAIL;
buffer.data[buffer.write] = byte;
// buffer.data[buffer.write & BUFFER_MASK] = byte; // absolut Sicher
buffer.write = next;
return SUCCESS;
}

uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return FAIL;
*pByte = buffer.data[buffer.read];
buffer.read = (buffer.read+1) & BUFFER_MASK;
return SUCCESS;
}
</syntaxhighlight>

=== FIFO mit C-Präprozessor ===

<syntaxhighlight lang="c">
#ifndef FIFO_H_
#define FIFO_H_

#include <stdint.h>

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[64];
} FIFO64_t;

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[128];
} FIFO128_t;

#define FIFO_init(fifo) { fifo._read = 0; fifo._write = 0; }

#define FIFO_available(fifo) ( fifo._read != fifo._write )

#define FIFO_read(fifo, size) ( \
(FIFO_available(fifo)) ? \
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
)

#define FIFO_write(fifo, data, size) { \
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
if(tmphead != fifo._read) { /* if buffer is not full */ \
fifo._write = tmphead; /* store new index */ \
fifo._buffer[tmphead] = data; /* store data in buffer */ \
} \
}

#define FIFO64_read(fifo) FIFO_read(fifo, 64)
#define FIFO64_write(fifo, data) FIFO_write(fifo, data, 64)

#define FIFO128_read(fifo) FIFO_read(fifo, 128)
#define FIFO128_write(fifo, data) FIFO_write(fifo, data, 128)

#endif /*FIFO_H_*/
</syntaxhighlight>

== Weblinks ==
* [http://en.wikipedia.org/wiki/Circular_buffer Circular buffer], englische Wikipedia

[[Kategorie:Grundlagen]]
[[Kategorie:Datenübertragung]]
[[Kategorie:Algorithmen und Arithmetik]]
[[Kategorie:Speicher und Dateisysteme]]

FIFO

2015-02-24T08:25:42Z

Kbuchegg: Text ergänzt und allgemeiner formuliert.

Ein FIFO (First-In-First-Out) ist ein Pufferspeicher nach dem "Warteschlangen-Prinzip". Pufferspeicher dienen dazu, für einen Prozessor Daten aufzufangen, die er noch nicht verarbeiten kann. Ein FIFO funktioniert definitionsgemäß so, dass das erste Element (First In), welches "hinten" in die Warteschlange eingefügt wird, später auch als erstes "vorne" herausgeholt wird (First Out). Das Gegenstück zum FIFO ist [[LIFO]].

Ein bekanntes Beispiel für einen FIFO-Speicher ist der des [[UART]]s im PC. Dieser sammelt ankommende Daten solange, bis er fast voll ist (meist 14 Bytes). Dann wird ein [[Interrupt]] ausgelöst und der Prozessor kann "auf einen Rutsch" alle Daten auf einmal auslesen. Ganz am Anfang hatten UARTs keinen FIFO und erzeugten für jedes empfangene Byte einen Interrupt, so wie es heute noch die meisten Mikrocontroller machen. Damit ist aber die CPU-Belastung wesentlich höher, was bei höheren Datenraten zu Problemen führen kann.

Die Umsetzung eines FIFOs in Software heißt Ringpuffer und weist auch eine feste Puffergröße auf. Wesentlicher Vorteil gegenüber der verketteten Liste ist die schnellere Ausführungszeit und der geringere Aufwand.

== Standard-Ringpuffer ==

Vorteile:
* Simpel
* Leicht verständlich
* Daten können auch vom Typ struct sein

Nachteile:
* Schnell aber nicht optimal

=== Beschreibung ===
{|
|-
|
[[Bild:Ringpuffer.png|300px]]
|
[[Bild:Circular buffer.png|200px]]
|}

Die Inhalte des Puffers werden in einem schlichten Array gespeichert und der Zugriff erfolgt über einen Integer-Index. Erreicht ein Index die Obergrenze springt dieser auf Null zurück. Topologisch ist dies äquivalent zu einem Ringschluss, bei dem man ja auch nach dem letzten Element wieder beim ersten angelangt ist. Man denke zb an das Zifferblatt einer Uhr, bei der nach der 59 wieder die 0 kommt. Ein größer-gleich statt nur eines ist-gleich Vergleichs ist sicherer gegenüber Programmfehlern, bei denen der Index verstellt wurde.
<syntaxhighlight lang="c">
write = write + 1;
if (write >= BUFFER_SIZE)
write = 0;
</syntaxhighlight>
Haben Lese- und Schreib-Index den gleichen Wert wird der Puffer als leer angesehen und es kann kein Element aus dem Puffer entnommen werden. Wenn write+1 und read identisch sind wird der Puffer als voll angesehen und es kann kein weiteres Element mehr im Puffer gespeichert werden. Nun fehlt noch der Sonderfall bei dem read gleich Null ist, hier funktioniert der write+1-Vergleich nicht mehr (wegen dem 'Überlauf' am Ende des Arrays, der den Ringschluss bewirkt) und die Abfrage einer zusätzlichen Bedingung ist zur Voll-Abfrage erforderlich.

<syntaxhighlight lang="c">
read == write => leer

write + 1 == read || read == 0 && write+1 == BUFFER_SIZE => voll
</syntaxhighlight>

Bei gleichzeitigem Zugriff zwischen dem Befüller (zb. einer UART-ISR) und dem Entnahmecode (zb. der Code in der Hauptschleife) muss ausgeschlossen werden, dass der Entnahmecode beim Lesen aus dem Puffer nicht durch den Interrupt unterbrochen werden kann. Denn während diese Funktion läuft ist zwischenzeitlich der read-Index in einem inkonsistenten Zustand. Erst nach Beendigung der Funktion spiegelt der read-Index wieder die Realität des Füllgrades wieder. Als Abhilfe dienen [[Interrupt#Atomarer_Datenzugriff|Atomare Abschnitte]], solche können durch keinen Interrupt unterbrochen werden. Die Radialkur deaktiviert alle Interrupts, besser ist die Deaktivierung eines einzelnen Interrupts. Es geht aber meistens auch so, da die FIFO Funktionen sehr kurz sind und daher auch die Interrupts nur kurz abgeschaltet werden. Im Allgemeinen werden versäumte Interrupts nach erneuter Aktivierung nachgeholt und gehen nicht verloren, so dass bereits anstehende Interrupts nur kurz verzögert werden. Solange die Interruptrate größer als die Ausführungsgeschwindigkeit der FIFO Funktionen ist, stellt das Abschalten der Interrupts daher auch in der Praxis meist kein allzugroßes Problem dar.

<syntaxhighlight lang="c">
cli()
ret = BufferOut(&var);
sei()
</syntaxhighlight>

Hilfreich ist die Initialisierung der Indizes (read, write) mit -1, denn damit kann man einen leere Ringpuffer von einem vollen unterscheiden. Initialisiert man nur mit 0, kann man einen leeren nicht von einem vollen mit read=write=0 unterscheiden.

Eine weitere Möglichkeit der Vereinfachung entsteht durch die Einführung einer "Counter" Variable, die den Füllstand des Buffers wiedergibt. Bei Einschreiben wird diese um +1 erhöht, beim Auslesen um 1 erniedrigt. Ist sie 0 ist der Buffer leer. Damit lässt sich die Codeeffizienz steigern, da die obigen Vergleiche kürzer ausfallen und sich auf nur diese eine Variable beschränken. Nachteilig ist allerdings, dass man eine weitere Variable im System hat und natürlich benötigen die entsprechenden Operationen zum Erhöhen bzw. Erniedrigen dieser Variable ja auch Ausführungszeit. Benötigt man im restlichen Code den Füllgrad der FIFO nicht als explizite Zahl, dann lohnt daher eine derartige Counter-Variable meistens nicht.

=== Code-Beispiel ===
<syntaxhighlight lang="c">
#define BUFFER_SIZE 23

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

uint8_t BufferIn(uint8_t byte)
{
//if (buffer.write >= BUFFER_SIZE)
// buffer.write = 0; // erhöht sicherheit

if (buffer.write + 1 == buffer.read || buffer.read == 0 && buffer.write + 1 == BUFFER_SIZE)
return FAIL; // voll

buffer.data[buffer.write] = byte;

buffer.write = buffer.write + 1;
if (buffer.write >= BUFFER_SIZE)
buffer.write = 0;
return SUCCESS;

}

uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return FAIL;
*pByte = buffer.data[buffer.read];

buffer.read = buffer.read + 1;
if (buffer.read >= BUFFER_SIZE)
buffer.read = 0;
return SUCCESS;
}
</syntaxhighlight>

== 2n-Ringpuffer - die schnellste Lösung ==

Vorteile:
* Durch Bitmaske auf den Feld-Index ''write'' kann der nicht "Amoklaufen" und beliebige Inhalte im Speicher überschreiben
* Sehr einfach, sehr schnell
* Daten können auch vom Typ ''struct'' sein
Nachteile:
* Nur Größenfaktoren von 2n möglich
* Nur in speziellen Fällen Pointerreferenz möglich

=== Beschreibung ===

Wenn der Index am oberen Ende angekommen ist springt er an den Anfang zurück. Die Definition der Obergrenze wird nicht durch einen Vergleich realisiert, sondern durch Modulo-Arithmetik. Dies kann sehr einfach und schnell durch Maskieren des Index-Werts umgesetzt werden.

Beispiel:
<syntaxhighlight lang="c">
( write + 1 ) & MASK

15 = 0b00001111
15 + 1 = 16 = 0b000010000
16 & MASK = 0b000010000 & 0b000001111 = 0b000000000
</syntaxhighlight>

Daraus folgt das ''write'' nur einen Wert zwischen 0 und 15 einnehmen kann. Das ganze funktioniert nur mit Zahlen der Reihe 2n.

Da der Puffer nur eine endliche Größe aufweist, muss eine voll/leer Indikation verfügbar sein. read == write bedeutet Puffer leer, entsprechend bedeutet write + 1 == read, dass keine weiteren Elemente mehr hinzugefügt werden können, denn sonst würde das Hinzufügen weiterer Daten einen Pufferüberlauf hervorrufen. Für die Behandlung des Pufferüberlaufs gibt es zwei Methoden, nichts tun und Fehler zurück geben oder ältesten Puffer-Inhalt verwerfen (read+1).

<syntaxhighlight lang="c">
read == ((write + 1) & MASK)
</syntaxhighlight>

Auch hier verhindert die Bitmaske einen möglichen Überlauf. Weiter zu beachten ist, dass ein Byte durch die voll/leer Indikation verloren geht, der Puffer hat hier nur eine größe von 15 statt 16 Byte

Und noch ein kleiner Trick. Bei einer Zahl der Reihe 2^n lässt sich auf einfache Weise immer eine passende Bitmaske erzeugen und man sieht gleichzeitig klar die Anzahl der genutzten Bytes.

<syntaxhighlight lang="c">
# define SIZE 16
# define MASK (SIZE-1)

16 = 0b010000
16 - 1 = 0b001111
</syntaxhighlight>

Im Normalbetrieb sollte der Puffer nie voll ausgereizt sein und wenn der Puffer bereits überläuft ist es für die Systemstabilität und Fehleranlyse oft schon zu spät, denn von einem nicht mehr funktionierenden Gerät lässt sich nur wenig Information herauskitzeln. Da kann ein Frühwarnsystem mehr bieten, wobei zwei Ausprägungen typisch sind, Höchstwert merken und eine Meldeschwelle einführen.

<syntaxhighlight lang="c">
freeMemory = (read - write - 1 ) & MASK);
if (freeMemory < floodmark)
floodmark = freeMemory;
</syntaxhighlight>

<syntaxhighlight lang="c">
if ( (read - write - 1 ) & MASK) <= FLOODMARK;
FloodmarkExcess();
</syntaxhighlight>

=== Code-Beispiel ===

<syntaxhighlight lang="c">
#define BUFFER_SIZE 16 // muss 2^n betragen (8, 16, 32, 64 ...)
#define BUFFER_MASK (BUFFER_SIZE-1) // Klammern auf keinen Fall vergessen

struct Buffer {
uint8_t data[BUFFER_SIZE];
uint8_t read; // zeigt auf das Feld mit dem ältesten Inhalt
uint8_t write; // zeigt immer auf leeres Feld
} buffer = {{}, 0, 0};

uint8_t BufferIn(uint8_t byte)
{
uint8_t next = ((buffer.write + 1) & BUFFER_MASK);
if (buffer.read == next)
return FAIL;
buffer.data[buffer.write] = byte;
// buffer.data[buffer.write & BUFFER_MASK] = byte; // absolut Sicher
buffer.write = next;
return SUCCESS;
}

uint8_t BufferOut(uint8_t *pByte)
{
if (buffer.read == buffer.write)
return FAIL;
*pByte = buffer.data[buffer.read];
buffer.read = (buffer.read+1) & BUFFER_MASK;
return SUCCESS;
}
</syntaxhighlight>

=== FIFO mit C-Präprozessor ===

<syntaxhighlight lang="c">
#ifndef FIFO_H_
#define FIFO_H_

#include <stdint.h>

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[64];
} FIFO64_t;

typedef struct {
uint8_t _read;
uint8_t _write;
uint8_t _buffer[128];
} FIFO128_t;

#define FIFO_init(fifo) { fifo._read = 0; fifo._write = 0; }

#define FIFO_available(fifo) ( fifo._read != fifo._write )

#define FIFO_read(fifo, size) ( \
(FIFO_available(fifo)) ? \
fifo._buffer[fifo._read = (fifo._read + 1) & (size-1)] : 0 \
)

#define FIFO_write(fifo, data, size) { \
uint8_t tmphead = ( fifo._write + 1 ) & (size-1); /* calculate buffer index */ \
if(tmphead != fifo._read) { /* if buffer is not full */ \
fifo._write = tmphead; /* store new index */ \
fifo._buffer[tmphead] = data; /* store data in buffer */ \
} \
}

#define FIFO64_read(fifo) FIFO_read(fifo, 64)
#define FIFO64_write(fifo, data) FIFO_write(fifo, data, 64)

#define FIFO128_read(fifo) FIFO_read(fifo, 128)
#define FIFO128_write(fifo, data) FIFO_write(fifo, data, 128)

#endif /*FIFO_H_*/
</syntaxhighlight>

== Weblinks ==
* [http://en.wikipedia.org/wiki/Circular_buffer Circular buffer], englische Wikipedia

[[Kategorie:Grundlagen]]
[[Kategorie:Datenübertragung]]
[[Kategorie:Algorithmen und Arithmetik]]
[[Kategorie:Speicher und Dateisysteme]]

FAQ

2014-12-02T12:14:48Z

Kbuchegg: /* Header File - wie geht das */

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

itoa() ist keine C-Standardfunktion (wohl aber ihre Umkehrung atoi() ). Auf manchen Compilern heisst diese Funktion dann folgerichtig _itoa(), wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Library [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

itoa( i, Buffer, 10 ); - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array Buffer groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei printf() (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

Typ ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
c char
d int
f float, double
ld long
u unsigned int
lu unsigned long
p pointer
s string
x ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
X ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

+ Vorzeichen wird immer ausgegeben
- Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
0 anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Wertebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man itoa() nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j 

Das Grundprinzip ist einfach: 
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> 2
8392 / 10 -> 839

839 % 10 -> 9
839 / 10 -> 83

83 % 10 -> 3
83 / 10 -> 8

8 % 10 -> 8
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j 

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit einen Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

Präprozessordefinitionen besitzen keine eigene Datentypen, da sie eine reine Textersetzungen durchführen. Deren Inhalte können aber ggf. zu Werten aufgelöst werden, die datentypbehaftet sind.

=Aktivieren der Floating Point Version von sprintf bei WinAVR bzw AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries'' In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous'' In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File - wie geht das =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen VarExtA bzw. VarExtB, die zu den jewiligen Funktionen A bzw. B gehören. Für dieses System soll eine Aufteilung erfolgen, so dass functionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define A_DEFAULT 5

int functionIntA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define A_DEFAULT 5

int functionA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll. Bei dem Makro A_DEFAULT kann es unterschiedliche Ansichten geben. Handelt es sich um einen Wert, den ein Aufrufer kennen soll, dann wird man das #define ins Header File verschieben (und aus dem C-File rausnehmen). Sieht man dieses #define aber als 'Privatsache' des C-Files, dann bleibt der #define dort wo er jetzt ist.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define A_DEFAULT 5

int functionA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SETTING_B 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur eine Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. CTC Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte TOP). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

FAQ

2014-12-02T12:11:18Z

Kbuchegg: Makro Syntax auf die uebliche Grossschreibung angepasst und so geaendert, dass es keinen Syntaxfehler gibt

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

itoa() ist keine C-Standardfunktion (wohl aber ihre Umkehrung atoi() ). Auf manchen Compilern heisst diese Funktion dann folgerichtig _itoa(), wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Library [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

itoa( i, Buffer, 10 ); - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array Buffer groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei printf() (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

Typ ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
c char
d int
f float, double
ld long
u unsigned int
lu unsigned long
p pointer
s string
x ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
X ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

+ Vorzeichen wird immer ausgegeben
- Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
0 anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Wertebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man itoa() nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j 

Das Grundprinzip ist einfach: 
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> 2
8392 / 10 -> 839

839 % 10 -> 9
839 / 10 -> 83

83 % 10 -> 3
83 / 10 -> 8

8 % 10 -> 8
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j 

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit einen Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

Präprozessordefinitionen besitzen keine eigene Datentypen, da sie eine reine Textersetzungen durchführen. Deren Inhalte können aber ggf. zu Werten aufgelöst werden, die datentypbehaftet sind.

=Aktivieren der Floating Point Version von sprintf bei WinAVR bzw AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries'' In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous'' In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File - wie geht das =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen. Für dieses System soll eine Aufteilung erfolgen, so dass funtionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define A_DEFAULT 5

int functionIntA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define A_DEFAULT 5

int functionA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define A_DEFAULT 5

int functionA( void )
{
VarExtA = A_DEFAULT;
VarIntA = VarExtB;
functionB();
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SETTING_B 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SETTING_B 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SETTING_B;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur eine Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. CTC Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte TOP). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

AVR-Tutorial: Speicher

2014-10-19T21:05:27Z

Kbuchegg: /* Flash-ROM */

== Speichertypen ==

Die AVR-Mikrocontroller besitzen 3 verschiedene Arten von Speicher:

<table border="1" class="wikitable">
<tr>
<th align="left">has</th>
<th align="left">Flash</th>
<th align="left">EEPROM</th>
<th align="left">RAM</th>
</tr>
<tr>
<th align="left">Schreibzyklen</th>
<td>>10.000</td>
<td>>100.000</td>
<td>unbegrenzt</td>
</tr>
<tr>
<th align="left">Lesezyklen</th>
<td>unbegrenzt</td>
<td>unbegrenzt</td>
<td>unbegrenzt</td>
</tr>
<tr>
<th align="left">flüchtig</th>
<td>nein</td>
<td>nein</td>
<td>ja</td>
</tr>
<tr>
<th align="left">Größe beim ATtiny2313</th>
<td>2 KB</td>
<td>128 Byte</td>
<td>128 Byte</td>
</tr>
<tr>
<th align="left">Größe beim ATmega8</th>
<td>8 KB</td>
<td>512 Byte</td>
<td>1 KB</td>
</tr>
<tr>
<th align="left">Größe beim ATmega32</th>
<td>32 KB</td>
<td>1 KB</td>
<td>2 KB</td>
</tr>

</table>

=== Flash-ROM ===

Das [[Speicher#Flash-ROM | '''Flash-ROM''']] der AVRs dient als Programmspeicher. Über den Programmieradapter werden die kompilierten Programme vom PC an den Controller übertragen und im Flash-ROM abgelegt. Bei der Programmausführung wird das ROM [[Digitaltechnik#Word | Wort]] für Wort ausgelesen und ausgeführt. Es lässt sich aber auch zur Speicherung von Daten nutzen (z. B. Texte für ein [[LCD]]). Vom laufenden Programm aus kann man das ROM normalerweise nur lesen, nicht beschreiben. Es kann beliebig oft ausgelesen werden, aber theoretisch nur ~10.000 mal beschrieben werden.

=== EEPROM ===

Das [[Speicher#EEPROM |'''EEPROM''']] ist wie das Flash ein nichtflüchtiger Speicher, die Daten bleiben also auch nach dem Ausschalten der Betriebsspannung erhalten. Es kann beliebig oft gelesen und mindestens 100.000 mal beschrieben werden. Bei den AVRs kann man es z. B. als Speicher für Messwerte oder Einstellungen benutzen.

=== RAM ===

Das [[Speicher#RAM |'''RAM''']] ist ein flüchtiger Speicher, d.h. die Daten gehen nach dem Ausschalten verloren. Es kann beliebig oft gelesen und beschrieben werden, weshalb es sich zur Speicherung von Variablen eignet für die die Register R0-R31 nicht ausreichen. Daneben dient es als Speicherort für den Stack, auf dem z. B. bei Unterprogrammaufrufen (rcall) die Rücksprungadresse gespeichert wird (siehe [[AVR-Tutorial:_SRAM | AVR-Tutorial: SRAM]]).

== Anwendung ==

=== Flash-ROM ===

Die erste und wichtigste Anwendung des Flash-ROMs kennen wir bereits: Das Speichern von Programmen, die wir nach dem Assemblieren dort hineingeladen haben. Nun sollen aber auch vom laufenden Programm aus Daten ausgelesen werden.

Um die Daten wieder auszulesen, muss man die Adresse, auf die zugegriffen werden soll, in den '''Z-Pointer''' laden. Der Z-Pointer besteht aus den Registern '''R30''' (Low-Byte) und '''R31''' (High-Byte), daher kann man das Laden einer Konstante wie gewohnt mit dem Befehl '''ldi''' durchführen. Statt R30 und R31 kann man übrigens einfach '''ZL''' und '''ZH''' schreiben, da diese Synonyme bereits in der include-Datei m8def.inc definiert sind.

Wenn die richtige Adresse erstmal im Z-Pointer steht, geht das eigentliche Laden der Daten ganz einfach mit dem Befehl '''lpm'''. Dieser Befehl, der im Gegensatz zu out, ldi usw. keine Operanden hat, veranlasst das Laden des durch den Z-Pointer addressierte Byte aus dem Programmspeicher in das Register '''R0''', von wo aus man es weiterverarbeiten kann.

Jetzt muss man nur noch wissen, wie man dem Assembler überhaupt beibringt, dass er die von uns festgelegten Daten im ROM platzieren soll und wie man dann an die Adresse kommt an der sich diese Daten befinden. Um den Programmspeicher mit Daten zu füllen, gibt es die Direktiven .db und .dw. In der Regel benötigt man nur .db, was folgendermaßen funktioniert:

<syntaxhighlight lang="avrasm">
daten:
.db 12, 20, 255, 0xFF, 0b10010000
</syntaxhighlight>

Direktiven wie .db sind Anweisungen an den Assembler, keine Prozessorbefehle. Von denen kann man sie durch den vorangestellten Punkt unterscheiden. In diesem Fall sagen wir dem Assembler, dass er die angegebenen Bytes nacheinander im Speicher platzieren soll; wenn man die Zeile also assembliert, erhält man eine Hex-Datei, die nur diese Daten enthält.

Aber was soll das '''daten:''' am Anfang der Zeile? Bis jetzt haben wir Labels nur als Sprungmarken verwendet, um den Befehlen '''rcall''' und '''rjmp''' zu sagen, an welche Stelle im Programm gesprungen werden soll. Würden wir in diesem Fall '''rjmp daten''' im Programm stehen haben, dann würde die Programmausführung zur Stelle '''daten:''' springen, und versuchen die sinnlosen Daten als Befehle zu interpretieren - was mit Sicherheit dazu führt, dass der Controller Amok läuft.

Statt nach '''daten:''' zu springen, sollten wir die Adresse besser in den Z-Pointer laden. Da der Z-Pointer aus zwei Bytes besteht, brauchen wir dazu zweimal den Befehl '''ldi''':

<syntaxhighlight lang="avrasm">
ldi ZL, LOW(daten*2) ; Low-Byte der Adresse in Z-Pointer
ldi ZH, HIGH(daten*2) ; High-Byte der Adresse in Z-Pointer
</syntaxhighlight>

Wie man sieht, ist das Ganze sehr einfach: Man kann die Labels im Assembler direkt wie Konstanten verwenden. Über die Multiplikation der Adresse mit zwei sollte man sich erst mal keine Gedanken machen: "Das ist einfach so." Wer es genauer wissen will schaut [[AVR-Tutorial:_Mehrfachverzweigung#Z-Pointer_leicht_verst.C3.A4ndlich | hier]] nach.

Um zu zeigen wie das alles konkret funktioniert, ist das folgende Beispiel nützlich:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

ldi R16, 0xFF
out DDRB, R16 ; Port B: Ausgang

ldi ZL, LOW(daten*2) ; Low-Byte der Adresse in Z-Pointer
ldi ZH, HIGH(daten*2) ; High-Byte der Adresse in Z-Pointer

lpm ; durch Z-Pointer adressiertes Byte
; in R0 laden
out PORTB, R0 ; an PORTB ausgeben

ende:
rjmp ende ; Endlosschleife

daten:
.db 0b10101010
</syntaxhighlight>

Wenn man dieses Programm assembliert und in den Controller überträgt, dann kann man auf den an Port B angeschlossenen LEDs das mit '''.db 0b10101010''' im Programmspeicher abgelegte Bitmuster sehen.

==== Fallbeispiel: Zeichenketten ====
Eine häufige Anwendung von '''lpm''' ist das Auslesen von Zeichenketten ("Strings") aus dem Flash-ROM und die Ausgabe an den seriellen Port oder ein LCD. Das folgende Programm gibt in einer Endlosschleife den Text "AVR-Assembler ist ganz einfach", gefolgt von einem Zeilenumbruch, an den UART aus.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17

.equ CLOCK = 4000000 ; Frequenz des Quarzes
.equ BAUD = 9600 ; Baudrate
.equ UBRRVAL = CLOCK/(BAUD*16)-1 ; Baudratenteiler

; hier geht das Programmsegment los

.CSEG
.org 0
ldi r16, low(RAMEND) ; Stackpointer initialisieren
out SPL, r16
ldi r16, high(RAMEND)
out SPH, r16

ldi temp, LOW(UBRRVAL) ; Baudrate einstellen
out UBRRL, temp
ldi temp, HIGH(UBRRVAL)
out UBRRH, temp

ldi temp, (1<<URSEL)|(3<<UCSZ0) ; Frame-Format: 8 Bit
out UCSRC, temp
sbi UCSRB, TXEN ; TX (Senden) aktivieren

loop:
ldi ZL, LOW(text*2) ; Adresse des Strings in den
ldi ZH, HIGH(text*2) ; Z-Pointer laden
rcall print ; Funktion print aufrufen
rcall wait ; kleine Pause
rjmp loop ; das Ganze wiederholen

; kleine Pause
wait:
ldi temp,0
wait_1:
ldi temp1,0
wait_2:
dec temp1
brne wait_2
dec temp
brne wait_1
ret

; print: sendet die durch den Z-Pointer adressierte Zeichenkette

print:
lpm ; Erstes Byte des Strings nach R0 lesen
tst R0 ; R0 auf 0 testen
breq print_end ; wenn 0, dann zu print_end
mov r16, r0 ; Inhalt von R0 nach R16 kopieren
rcall sendbyte ; UART-Sendefunktion aufrufen
adiw ZL, 1 ; Adresse des Z-Pointers um 1 erhöhen
rjmp print ; wieder zum Anfang springen
print_end:
ret

; sendbyte: sendet das Byte aus R16 über das UART

sendbyte:
sbis UCSRA, UDRE ; warten bis das UART bereit ist
rjmp sendbyte
out UDR, r16
ret

; Konstanten werden hier im Flash abgelegt

text:
.db "AVR-Assembler ist ganz einfach",10,13,0
; Stringkonstante, durch eine 0 abgeschlossen
; die 10 bzw. 13 sind Steuerzeichen für Wagenrücklauf und neue Zeile
</syntaxhighlight>

Neuere AVR-Controller besitzen einen erweiterten Befehlssatz. Darunter befindet sich auch der folgende Befehl:

<syntaxhighlight lang="avrasm">
lpm r16, Z+
</syntaxhighlight>

Dieser Befehl liest ein Byte aus dem Flash und speichert es in einem beliebigen Register, hier r16. Danach wird der Zeiger Z um eins erhöht. Für die neuen Controller, wie ATmegas kann das Codebeispiel also so abgeändert werden:

<syntaxhighlight lang="avrasm">
; print: sendet die durch den Z-Pointer adressierte Zeichenkette
print:
lpm r16, Z+ ; Erstes Byte des Strings nach r16 lesen
tst r16 ; r16 auf 0 testen
breq print_end ; wenn 0, dann zu print_end
rcall sendbyte ; UART-Sendefunktion aufrufen
rjmp print ; wieder zum Anfang springen
print_end:
ret
</syntaxhighlight>

Wenn man bei .db einen Text in doppelten Anführungszeichen angibt, werden die Zeichen automatisch in die entsprechenden ASCII-Codes umgerechnet:

<syntaxhighlight lang="avrasm">
.db "Test", 0
; ist äquivalent zu
.db 84, 101, 115, 116, 0
</syntaxhighlight>

Damit das Programm das Ende der Zeichenkette erkennen kann, wird eine 0 an den Text angehängt.

Das ist doch schonmal sehr viel praktischer, als jeden Buchstaben einzeln in ein Register zu laden und abzuschicken. Und wenn man statt '''sendbyte''' einfach die Routine '''lcd_data''' aus dem 4. Teil des Tutorials aufruft, dann funktioniert das gleiche sogar mit dem LCD!

==== Neue Assemblerbefehle ====

<syntaxhighlight lang="avrasm">
lpm ; Liest das durch den Z-Pointer
; addressierte Byte aus dem Flash-ROM
; in das Register R0 ein.

lpm [Register], Z ; Macht das gleiche wie lpm, jedoch in
; ein beliebiges Register

lpm [Register], Z+ ; Erhöht zusätzlich den Z-Zeiger

tst [Register] ; Prüft, ob Inhalt eines Registers
; gleich 0 ist.

breq [Label] ; Springt zu [Label], wenn der
; vorhergehende Vergleich wahr ist.

adiw [Register], [Konstante] ; Addiert eine Konstante zu einem
; Registerpaar. [Register] bezeichnet das
; untere der beiden Register.
; Kann nur auf die Registerpaare
; R25:R24, R27:R26, R29:R28 und R31:R30
; angewendet werden.
</syntaxhighlight>

=== EEPROM ===

Den Flash Speicher kann man also benutzen, um dort Daten abzulegen, die sich während eines Programmlaufs nicht verändern. Irgendwelche Tabellen oder konstante Texte. Aber des öfteren möchte man auch die Möglichkeit haben, Daten zu speichern und wieder zu lesen, die sich während des Programmlaufs ändern. Ganz besonders möchte man eine Speicherfläche zur Verfügung haben, die ihren Inhalt auch dann behält, wenn dem µC die Versorgungsspannung abgedreht wird. Man denke z.B. an irgendwelche Konfigurationsdaten oder an Informationen, wie weit der µC in der Bearbeitung von Daten vorangekommen ist oder irgendwelche Statistikdaten, die auch nach einem Stromausfall noch verfügbar sein sollen. In solchen Fällen kommt das EEPROM zum Einsatz

==== Lesen ====

Als erstes muss geprüft werden, ob ein vorheriger Schreibzugriff schon abgeschlossen ist. Danach wird die EEPROM-Adresse von der gelesen werden soll in das IO-Registerpaar '''EEARH/EEARL''' (EEPROM Address Register) geladen. Da der ATmega8 mehr als 256 Byte EEPROM hat, passt die Adresse nicht in ein einziges 8-Bit-Register, sondern muss in zwei Register aufgeteilt werden: EEARH bekommt das obere Byte der Adresse, EEARL das untere Byte. Dann löst man den Lesevorgang durch das Setzen des Bits '''EERE''' (EEPROM Read Enable) im IO-Register '''EECR''' (EEPROM Control Register) aus. Das gelesene Byte kann sofort aus dem IO-Register '''EEDR''' (EEPROM Data Register) in ein normales CPU-Register kopiert und dort weiterverarbeitet werden.

Wie auch das Flash-ROM kann man das EEPROM über den ISP-Programmer programmieren. Die Daten, die im EEPROM abgelegt werden sollen, werden wie gewohnt mit .db angegeben; allerdings muss man dem Assembler natürlich sagen, dass es sich hier um Daten für das EEPROM handelt. Das macht man durch die Direktive '''.eseg''', woran der Assembler erkennt, dass alle nun folgenden Daten für das EEPROM bestimmt sind.

Damit man die Bytes nicht von Hand abzählen muss um die Adresse herauszufinden, kann man auch im EEPROM-Segment wieder Labels einsetzen und diese im Assemblerprogramm wie Konstanten verwenden.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

; hier geht die Programmsektion los
.cseg

ldi r16, low(RAMEND) ; Stackpointer initialisieren
out SPL, r16
ldi r16, high(RAMEND)
out SPH, r16

ldi r16, 0xFF
out DDRB, r16 ; Port B Ausgang

ldi ZL,low(daten) ; Z-Zeiger laden
ldi ZH,high(daten)
rcall EEPROM_read ; Daten aus EEPROM lesen
out PORTB, r16

loop:
rjmp loop

EEPROM_read:
sbic EECR,EEWE ; prüfe ob der vorherige Schreibzugriff
; beendet ist
rjmp EEPROM_read ; nein, nochmal prüfen

out EEARH, ZH ; Adresse laden
out EEARL, ZL
sbi EECR, EERE ; Lesevorgang aktivieren
in r16, EEDR ; Daten in CPU Register kopieren
ret

; Daten im EEPROM definieren
.eseg
daten:
.db 0b10101010
</syntaxhighlight>

Wenn man dieses Programm assembliert, erhält man außer der .hex-Datei noch eine Datei mit der Endung '''.eep'''. Diese Datei enthält die Daten aus dem EEPROM-Segment (.eseg), und muss zusätzlich zu der hex-Datei in den Controller programmiert werden.

Das Programm gibt die Binärzahl 0b10101010 an den Port B aus, das heißt jetzt sollte jede zweite LED leuchten.

Natürlich kann man auch aus dem EEPROM Strings lesen und an den UART senden:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16

.equ CLOCK = 4000000 ; Frequenz des Quarzes

.equ BAUD = 9600 ; Baudrate
.equ UBRRVAL = CLOCK/(BAUD*16)-1 ; Baudratenteiler

; hier geht das Programmsegment los

.CSEG

; Hauptprogramm
main:
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp
ldi temp, HIGH(RAMEND)
out SPH, temp

ldi temp, LOW(UBRRVAL) ; Baudrate einstellen
out UBRRL, temp
ldi temp, HIGH(UBRRVAL)
out UBRRH, temp

ldi temp, (1<<URSEL)|(3<<UCSZ0) ; Frame-Format: 8 Bit
out UCSRC, temp
sbi UCSRB, TXEN ; TX (Senden) aktivieren

ldi ZL, low(text1) ; ersten String senden
ldi ZH, high(text1) ; Z-Pointer laden
rcall EEPROM_print

ldi ZL, low(text2) ; zweiten String senden
ldi ZH, high(text2) ; Z-Pointer laden
rcall EEPROM_print

loop:
rjmp loop ; Endlosschleife

; EEPROM Lesezugriff auf Strings + UART Ausgabe

EEPROM_print:
sbic EECR,EEWE ; prüf ob der vorherige Schreibzugriff
; beendet ist
rjmp EEPROM_print ; nein, nochmal prüfen

out EEARH, ZH ; Adresse laden
out EEARL, ZL

sbi EECR, EERE ; Lesevorgang aktivieren
in temp, EEDR ; Daten in CPU Register kopieren
tst temp ; auf 0 testen (=Stringende)
breq eep_print_end ; falls 0, Funktion beenden
rcall sendbyte ; ansonsten Byte senden...
adiw ZL,1 ; Adresse um 1 erhöhen...
rjmp EEPROM_print ; und zum Anfang der Funktion
eep_print_end:
ret

; sendbyte: sendet das Byte aus "data" über den UART

sendbyte:
sbis UCSRA, UDRE ; warten bis das UART bereit ist
rjmp sendbyte
out UDR, temp
ret

; hier wird der EEPROM-Inhalt definiert

.ESEG

text1:
.db "Strings funktionieren auch ", 0
text2:
.db "im EEPROM",10,13, 0
</syntaxhighlight>

==== Schreiben ====

Als erstes muss geprüft werden, ob ein vorheriger Schreibzugriff schon abgeschlossen ist. Danach wird die EEPROM-Adresse, auf die geschrieben wird, in das IO-Register '''EEAR''' ('''EE'''PROM '''A'''ddress '''R'''egister) geladen. Dann schreibt man die Daten, welche man auf der im Adressregister abgespeicherten Position ablegen will ins Register '''EEDR''' ('''EE'''PROM '''D'''ata '''R'''egister). Als nächstes setzt man das '''EEMWE''' Bit im EEPROM-Kontrollregister '''EECR''' ('''EE'''PROM '''C'''ontrol '''R'''egister) um den Schreibvorgang vorzubereiten. Nun wird es zeitkritisch - es darf nun keinesfalls ein Interrupt dazwischenfahren - denn man muss innerhalb von 4 Taktzyklen das '''EEWE''' Bit setzen um den Schreibvorgang auszulösen. Um das unter allen Bedingungen sicherzustellen werden die Interrupts kurz gesperrt. Danach startet der Schreibvorgang und läuft automatisch ab. Wenn er beendet ist, wird von der Hardware das '''EEWE''' Bit im Register '''EECR''' wieder gelöscht.

In diesem Beispiel werden Zeichen per UART und Interrupt empfangen und nacheinander im EEPROM gespeichert. Per Terminalprogramm kann man nun bis zu 512 Zeichen in den EEPROM schreiben. Per Programmieradapter kann man denn EEPROM wieder auslesen und seine gespeicherten Daten anschauen.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def sreg_save = r17

.equ CLOCK = 4000000

.equ BAUD = 9600
.equ UBRRVAL = CLOCK/(BAUD*16)-1

; hier geht das Programmsegment los

.CSEG
.org 0x00
rjmp main

.org URXCaddr
rjmp int_rxc

; Hauptprogramm
main:
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp
ldi temp, HIGH(RAMEND)
out SPH, temp

ldi temp, LOW(UBRRVAL) ; Baudrate einstellen
out UBRRL, temp
ldi temp, HIGH(UBRRVAL)
out UBRRH, temp

ldi temp, (1<<URSEL)|(3<<UCSZ0) ; Frame-Format: 8 Bit
out UCSRC, temp

sbi UCSRB, RXCIE ; Interrupt bei Empfang
sbi UCSRB, RXEN ; RX (Empfang) aktivieren

ldi ZL,low(daten) ; der Z-Zeiger wird hier exclusiv
ldi ZH,high(daten) ; für die Datenadressierung verwendet

sei ; Interrupts global aktivieren

loop:
rjmp loop ; Endlosschleife (ABER Interrupts!)

; Interruptroutine wird ausgeführt,
; sobald ein Byte über den UART empfangen wurde

int_rxc:
push temp ; temp auf dem Stack sichern
in temp,sreg ; SREG sicher, muss praktisch in jeder
; Interruptroutine gemacht werden
push temp

in temp, UDR ; empfangenes Byte lesen
rcall EEPROM_write ; Byte im EEPROM speichern
adiw ZL,1 ; Zeiger erhöhen
cpi ZL,low(EEPROMEND+1) ; Vergleiche den Z Zeiger
ldi temp,high(EEPROMEND+1) ; mit der maximalen EEPROM Adresse +1
cpc ZH,temp
brne int_rxc_1 ; wenn ungleich, springen
ldi ZL,low(Daten) ; wenn gleich, Zeiger zurücksetzen
ldi ZH,high(Daten)
int_rxc_1:

pop temp
out sreg,temp
pop temp ; temp wiederherstellen
reti

; der eigentliche EEPROM Schreibzugriff
; Adresse in ZL/ZH
; Daten in temp

EEPROM_write:
sbic EECR, EEWE ; prüfe ob der letzte Schreibvorgang beendet ist
rjmp EEPROM_write ; wenn nein, nochmal prüfen

out EEARH, ZH ; Adresse schreiben
out EEARL, ZL ;
out EEDR,temp ; Daten schreiben
in sreg_save,sreg ; SREG sichern
cli ; Interrupts sperren, die nächsten
; zwei Befehle dürfen NICHT
; unterbrochen werden
sbi EECR,EEMWE ; Schreiben vorbereiten
sbi EECR,EEWE ; Und los !
out sreg, sreg_save ; SREG wieder herstellen
ret

; hier wird der EEPROM-Inhalt definiert
.ESEG

Daten:
.db 0
</syntaxhighlight>

=== SRAM ===

Die Verwendung des SRAM wird in einem anderen Kapitel erklärt: [[AVR-Tutorial: SRAM]]

== Siehe auch ==

* [[Adressierung]]

----

{{Navigation_zurückhochvor|
zurücktext=UART|
zurücklink=AVR-Tutorial: UART|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=Timer|
vorlink=AVR-Tutorial: Timer}}

[[Category:AVR-Tutorial|Speicher]]
[[Kategorie:Speicher und Dateisysteme]]

Operationsverstärker-Grundschaltungen

2014-09-29T13:10:26Z

Kbuchegg:

== Idealisiertes Modell eines OPV==

=== Anschlüsse ===
Ein Operationsverstärker hat zwei Eingänge (+) und (-) und einen Ausgang
(UA). Außerdem verfügt er über eine positive und eine negative
Spannungsversorgung (V+) und (V-).

=== Spannungsversorgungen ===
Die Spannungsversorgungen sollen zunächst nicht interessieren. Sie
werden in Schaltungen oft nicht eingezeichnet.
In der Praxis ist es jedoch wichtig zu wissen, dass die Ausgangsspannung immer zwischen (V+) und (V-) liegt. Die Ausgangsspannung des OPV kommt schließlich dadurch zustande, dass der Ausgang über einen Transistor mehr oder weniger hochohmig mit den beiden Versorgungsspannungen verbunden wird.

Wenn man einen OPV also mit +5V versorgt, so kann der OPV im besten Fall am Ausgang +5V erzeugen. Man würde in diesem Fall von einem "Rail-to-Rail" Operationsverstärker sprechen.
Bei vielen Operationsverstärkern ist die maximal mögliche Ausgangsspannung geringer als die Versorgungsspannung. Ein mit +5V Spannungsversorgung beschalteter OPV kann dann beispielsweise nur +4V Ausgangsspannung erzeugen.

| \
| \
-- | - \
| \_______
| /
-- | + /
| /
| /

=== Ausgang ===
Der Ausgang des OPV ist eine ideale Spannungsquelle. Das bedeutet, dass die
Ausgangsspannung unabhängig davon ist, was ausgangsseitig an den OPV
angeschlossen wird.
In der Praxis gilt dieses Modell häufig nur bei "sinnvollen Anwendungen". So ist beispielsweise der Ausgangsstrom des OPV nach oben begrenzt (typischerweise im mA-Bereich), und manche OPV schwingen sehr leicht, wenn man sie kapazitiv belastet.

=== Eingänge ===
Die Eingänge eines OPV sind hochohmig, d. h., es handelt sich nur um "Messfühler", die keinen Strom führen.
Achtung: Die Eingangsschutzbeschaltung (Dioden von GND und gegen VCC) bei manchen OPVs kann jedoch dazu führen, dass Strom in den Eingang fliesst, wenn dessen Betriebsspannung z.B. abgeschaltet ist.

=== Funktionsweise ===
Der OPV mißt zu jeder Zeit die Differenz <math>U_D = U(+) - U(-)</math> der
Eingangsspannungen.

Ist die Spannung an (+) größer als an (-), so erhöht der OPV die
Ausgangsspannung.
Ist die Spannung an (+) niedriger als an (-), so vermindert der OPV die
Ausgangsspannung.

Das Ergebnis dieses Vorgangs wird häufig über die Gleichung:

<math>U_a = v \cdot U_D</math>

beschrieben, wobei <math>v</math> eine sehr große Zahl (10^4...10^6) ist.

Mit Hilfe der beschriebenen Funktionsweise lassen sich alle grundlegenden Schaltungen herleiten.

=== Beispiel ===

Betrachtet wird die invertierende Grundschaltung nach Abbildung a) im Abschnitt [[Operationsverstärker-Grundschaltungen#Verstärkergrundschaltungen|Verstärkergrundschaltungen]].

[[Bild:Op-verstaerker-a.png]]

Für die Pfeilrichtungen der Spannungen und Ströme gilt:

<math>U_e</math>: von oben nach unten

<math>I_{R3}</math>: von links nach rechts

Die Spannung am (+)Eingang ist gleich Null. Die Spannung am (-)Eingang wird durch die Spannungsquelle <math>U_e</math> und durch die im OPV befindliche und mit dem Ausgang verbundene Spannungsquelle des OPV manipuliert.

* Ist die Spannung am (-)Eingang negativ, so erhöht der Operationsverstärker die Ausgangsspannung. Dadurch wird durch die Rückführung über den Widerstand auch die Spannung am (-)Eingang positiver. Und zwar so lange, bis die Spannung am (-)Eingang gleich groß ist, wie die Spannung am (+)Eingang, also U(-)=0V.
* Ist die Spannung am (-)Eingang positiv, so vermindert der Operationsverstärker die Ausgangsspannung. Dadurch wird durch die Rückführung über den Widerstand auch die Spannung am (-)Eingang negativer. Und zwar so lange, bis die Spannung am (-)Eingang gleich groß ist, wie die Spannung am (+)Eingang, also U(-)=0V.

Der Operationsverstärker wird also die Spannungen an (+) und (-) angleichen. Das passiert immer dann, wenn der Ausgang mit dem (-)Eingang verbunden ist. Der Trick in dieser Schaltung besteht darin, dass von der Ausgangsspannung nur ein Teil wieder rückgeführt wird. Die Spannung U_e ist daher höher, als der Teil der benötigt wird, um die Spannungen an den Eingängen aneinander anzugleichen.
Man nennt das Prinzip "Gegenkopplung". Auf diese Art und Weise funktionieren alle analogen OPV-Schaltungen.

Da an (+) Massepotential anliegt, wird somit auch (-) daran angeglichen, und so liegt an <math>R_3</math> die Spannung <math>U_e</math> an. Daher gilt:
<math>I_{R3}=\frac{U_e}{R_3}.</math>

Da der (-)Eingang hochohmig ist, fließt <math>I_{R3}</math> über <math>R_4</math> weiter zum OPV-Ausgang.

Ua ist die Spannung vom Ausgang zur (virtuellen) Masse am (-)Eingang.
(--> Pfeil einzeichnen und klarmachen, daß es egal ist, ob der Pfeil vom
Ausgang zur Masse geht oder vom Ausgang "entgegen der Stromrichtung" zur
virtuellen Masse an (-)!)

Mit Hilfe von <math>I_{R3}=\frac{U_e}{R_3}</math> ergibt sich:

<math>U_a = -R_4 \cdot I_{R3} = -{{R_4} \over {R_3}} \cdot U_e.</math>

Die Energie für den Stromtransport über <math>R_4</math> stammt vom OPV! Sobald die Ladungen ausgehend von der Spannungsquelle <math>U_e</math> die virtuelle Masse an (-) erreicht haben, hat <math>U_e</math> seine gesamte Energie abgegeben.

== Reale OPs / Kennwerte ==
Abweichend vom idealen OP besitzen reale OPs diverse Einschränkungen und Kennwerte, die sie für verschiedene Einsätze mehr oder weniger prädestinieren.

=== Leerlaufverstärkung ===
Die Leerlaufverstärkung gibt an, wie stark sich das Ausgangssignal i.A. der Änderung eines Eingangsignals statisch ändert, bzw nach dem Einschwingen erreichen könnte, wenn es nicht durch die Betriebsgrenzen limitiert wäre.

=== Verstärkungs-Bandbreiteprodukt ===
Das Verstärkungs-Bandbreiteprodukt gibt an, bei welcher Verstärkung welche Bandbreite erreicht werden kann. Durch Rückkopplung kann die Verstärkung eingestellt werden. Bei kleinerer Verstärkung ergibt sich somit eine höhere Bandbreite, wenn das Produkt aus beiden konstant ist. Die Bandbreite bei der Verstärkung eins heißt Transitfrequenz. Das Verstärkungs-Bandbreiteprodukt ist entscheidend für das Kleinsignalverhalten.

=== Anstiegszeit ===
Bestimmend für das Großsignalverhalten ist neben dem Verstärkungs-Bandbreiteprodukt die Anstiegszeit (slew rate), da bei hohen Ausgangsamplituden die Ausgangskurve eventuell zu steil wird, um richtig wiedergegeben zu werden.

=== Gleichtaktverstärkung ===
Infolge des inhomogenen Aufbaus der internen Verstärkerstufen werden die beiden Eingangssignale nicht exakt gleich verstärkt, was in einen Gleichanteil und einen Differenzanteil aufgeteilt werden kann. Der nicht erwünschte Gleichtakt (engl. ''common mode'') ist dabei ein Maß für die Qualität des OP.

== Verstärkergrundschaltungen ==
=== Grundbeschaltung mit Berechnung ===
[[Bild:Op-verstaerker-a.png]] [[Bild:Op-verstaerker-b.png]]

In a) und b) verwenden wir den OP als Verstärker und nutzen hier die Möglichkeit der Gegenkopplung, um definierte Verstärkungen zu erhalten. Wir gehen wieder davon aus, dass der OP ein ideales Bauteil ist und daher seine Leerlaufverstärkung unendlich ist. Ebenso betrachten wir den Eingangswiderstand als unendlich.

In '''a)''' ist ein invertierender Verstärker mit einem OP dargestellt. Durch die Widerstände R3 und R4 wird die Verstärkung bestimmt:

:<math>V = \frac{U_a}{U_e} = -\frac{R_4}{R_3}</math>

Das Verhältnis der beiden Widerstände bestimmt also die Verstärkung und somit die Ausgangsspannung:

:<math>U_a = -\frac{R_4}{R_3} \cdot U_e </math>

oder auch

:<math>U_a = V \cdot U_e</math>

Das negative Vorzeichen drückt aus, dass es sich um einen invertierenden Verstärker handelt.

Beim nichtinvertierenden Verstärker '''b)''' finden wir auch eine Rückkopplung über R6 zum invertierenden Eingang des OP. Die Verstärkung wird durch das Gegenkopplungsnetzwerk R6 und R7 bestimmt. Hier ist:

:<math>V = 1 + \frac{R6}{R7}</math>

Eine Verstärkung von 1 ist sinnvoll, wenn eingangsseitig eine Spannungsquelle mit hohem Innenwiderstand verwendet wird. Für <math>\frac{R6}{R7} \to 0</math> heißt die Schaltung "Spannungsfolger".

Kleinere Werte als 1 lassen sich nicht realisieren. Die Ausgangsspannung errechnet sich also so:

:<math>U_a = U_e \cdot \left (1 + \frac{R_6}{R_7}\right )</math>

Beispiel: Eine Eingangsspannung von 0,5 V soll auf den Wert 5 V verstärkt werden, es ist also eine Verstärkung V von 10 benötigt. R7 ist mit 10 kΩ vorgegeben. Also ist das Verhältnis

:<math>\frac{R_6}{R_7} = V - 1</math>

Bei einem Wert von 10 kΩ für R7 errechnet sich R6 zu

:<math>
R6 = (V - 1) \cdot R7
= (10 - 1) \cdot 10\,\mathrm{k\Omega}
= 90\,\mathrm{k\Omega}
</math>

Die Ausgangsspannung Ua wird also:

:<math>
U_a = U_e \cdot \left (1 + \frac{R_6}{R_7}\right )
= 0,5\,\mathrm{V} \cdot \left (1 + \frac{90\,\mathrm{k\Omega}}{10\,\mathrm{k\Omega}}\right)
= 5\,\mathrm{V}
</math>

=== Nichtinvertierender Verstärker mit Offset ===
Eine Abwandlung des nichtinvertierenden Verstärkers erlaubt es, einen konstanten Offset vorzugeben. D.h. von der zu verstärkenden Eingangsspannung U(e) wird eine konstante Spannung U(o) abgezogen und die Differenz verstärkt. Auf der Ausgangsspannung U(a) findet sich die Offsetspannung U(o) allerdings wieder.
[[Bild:Op-verstaerker-offset.png]]

Es gilt:

Offsetspannung:
:<math>
U_o = U_V \cdot \frac{R2}{R1 + R2}
</math>
mit U(V) = Versorgungsspannung an R1

Verstärkung:
:<math>
V = 1 + \frac{R3}{\frac{R1 \cdot R2}{R1 + R2}}
</math>

Ausgangsspannung:
:<math>
U_a = (U_e - U_o) \cdot V + U_o
</math>

Der Vorteil dieser Schaltung ist, daß nur die Differenz verstärkt wird. Damit kann eine größere Verstärkung gewählt werden. Zu berücksichtigen ist dabei, daß die Ausgangsspannung U(a) um die Offsetspannung U(o) überlagert ist.

=== Spannungsfolger (Impedanzwandler) ===

[[Bild:Op-spannungsfolger1.png]]

Eine Abart des nichtinvertierenden Verstärkers stellt der Spannungsfolger dar. Beim nichtinvertierenden Verstärker errechnet sich die Ausgangsspannung aus:

:<math>U_a = U_e \cdot \left (1 + \frac{R_2}{R_1}\right )</math>

Wenn wir R2 auf 0Ω (mit R1 > 0) oder R1 auf unendlich (mit R2 < ∞) ändern, erhalten wir daher:

:<math>V = 1 + \frac{R_2}{R_1} = 1</math>

Ein Spannungsfolger hat also eine Verstärkung V von 1.

Umgezeichnet sieht die Schaltung so aus:

[[Bild:Op-spannungsfolger2.png]]

Was soll das nun? Wir nutzen die Eigenschaft, dass ein idealer OP einen unendlichen Eingangswiderstand und einen Ausgangswiderstand von 0Ω hat. Real sieht das natürlich anders aus: so liegt der Eingangswiderstand Re bei normalen OPs in der Größenordnung von 1MOhm bis <math>10^{15} \Omega</math>, der Ausgangswiderstand Ra im Bereich 20Ω bis 1kOhm. Deshalb spricht man bei dieser Schaltung von einem Impedanzwandler. Eine solche Schaltung kann also aus einer relativ hochohmigen Spannungsquelle eine niederohmige, durch Folgeschaltungen belastbare Spannungsquelle machen.

[[Bild:Op-spannungsfolger3.png|left]]

In dem nebenstehenden Beispiel ist eine einfache Möglichkeit zur Erzeugung einer Referenzspannung gezeigt. Es kommt eine normale Stabilisierungsschaltung mit einer Zenerdiode zur Anwendung, die aber nicht mehr die schlechten Eigenschaften der Standardbeschaltung mit lediglich Widerstand und Zenerdiode hat. Bei einer Zenerdiode hängt die genaue Spannung davon ab, welcher Strom durch sie fliesst. Dieser Strom (und damit auch die Höhe der Zenerspannung) würde sich aber ändern, wenn ein Verbraucher die Zenerdiode direkt mit seinem Stromfluss belasten würde. Als Folge davon würde die Spannungslage der Zenerdiode je nach Verbraucher leicht schwanken. Durch den Spannungsfolger wird das verhindert, weil der jetzt den vom Verbraucher gezogenen Strom bereitstellt.

{{Clear}}

[[Bild:Op-spannungsfolger4.png|left]]

Eine weitere Anwendungsmöglichkeit wäre das hochohmige Auskoppeln einer Brückenspannung. Die Brückenschaltung selbst wird durch Folgeschaltungen nicht mehr belastet, alle anderen Eigenschaften bleiben erhalten.

{{Clear}}

=== Der Komparator ===

[[Bild:Op-komp-a.png]] [[Bild:Op-komp-b.png]]

In der einfachsten Beschaltung des Operationsverstärkers erhält man einen Komparator. Es fällt auf, dass kein Gegenkopplungsnetzwerk vorhanden ist. Der OP arbeitet daher mit seiner vollen Leerlaufverstärkung Vo. Dies bedeutet, dass bereits eine kleine Eingangsspannung genügt, um den OP in die Begrenzung zu treiben. Das heißt, die Ausgangsspannung Ua wird annähernd die Betriebsspannung erreichen.

Beim Komparator gibt es zwei Möglichkeiten der Beschaltung: die invertierende nach a) und die nichtinvertierende Beschaltung nach b).

'''Berechnungsbeispiel für Schaltung b)'''

Angenommen die Leerlaufverstärkung Vo von 40000 und eine Eingangsspannung von 0,1 Volt. Die Betriebsspannungen Vcc und Vee legen wir auf +/- 24 V fest. Damit ergibt sich theoretisch für Ua:

:<math>U_a = V_0 \cdot U_e = 40000 \cdot 0,1\,\mathrm{V} = 4000\,\mathrm{V}</math>

Das ist natürlich ein unrealistischer Wert, da Ua nicht höher sein kann als die Betriebsspannung. Also anders ausgedrückt: Bei welcher Spannung Ue erreicht der OP seine Aussteuerungsgrenze?

:<math>U_e = V_{cc} / V_0 = 24\,\mathrm{V} / 40000 = 0,6\,\mathrm{mV}</math>

Das bedeutet, dass eine Spannung von 0,6 mV ausreicht um den Komparator in die Begrenzung zu treiben.

Das gleiche gilt auch für den invertierenden Komparator, allerdings wird hier der OP in die negative Begrenzung gebracht.

:<math>-U_a = V_0 \cdot U_e</math>

So hat der Komparator nun einen einstellbaren Schaltpunkt.

[[Bild:Op-komp-c.PNG]]

=== Der Addierer (Summierverstärker) ===

[[Bild:Op-addierer.png]]

Ein als invertierender Verstärker beschalteter OP lässt sich so beschalten, dass ein Summensignal aus den Eingangsspannungen gebildet wird. Um die Funktion deutlich zu machen, ist eine Betrachtung der einzelnen Ströme nötig.

In einem invertierenden Verstärker wird sich die Ausgangsspannung immer so einstellen, dass der invertierende Eingang Massepotential hat. Die virtuelle Masse (VM) unterscheidet sich von einer "normalen" Masse dadurch, dass das Potential durch einen Regelungsvorgang zustande kommt.
An der virtuellen Masse (VM) gilt die Knotenpunktregel, wonach die Summe der zufließenden Ströme gleich der Summe der abfließenden Ströme ist.

:<math>I_1 + I_2 = -I_3</math>

Sofern <math>U_{e1}</math> und <math>U_{e2}</math> bekannt sind, lässt sich die Gleichung umformen in:

:<math>\frac{U_{e1}}{R_1} + \frac{U_{e2}}{R_2} = -\frac{U_a}{R_3}</math>

Nach Ua aufgelöst ergibt sich:

:<math>-U_a = \left (U_{e1} \cdot \frac{R_3}{R_1}\right ) + \left (U_{e2} \cdot \frac{R_3}{R_2}\right ) + ... + \left (U_{en} \cdot \frac{R_3}{R_n}\right )</math>

Einen Sonderfall gibt es, wenn die Widerstände R1 und R2 gleich sind. Dann gilt

:<math>R_1 = R_2 = R_x</math>

und damit

:<math>-U_a = \frac{R_3}{R_x} \cdot (U_{e1} + U_{e2})</math>.

=== Der Subtrahierer (Differenzverstärker) ===

[[Bild:Op-subtrahierer.png]]

Ein Subtrahierer ist die Zusammenschaltung eines invertierenden und eines nichtinvertierenden Verstärkers. Schliessen wir Punkt Ue1 nach Masse kurz und steuern Ue2 an, arbeitet die Schaltung als nichtinvertierender Verstärker. Wird Ue2 nach Masse verbunden und Ue1 angesteuert, verhält sich die Schaltung als invertierender Verstärker (R7 vorerst nicht beachten).

Für den 1. Fall (nichtinvertierender Verstärker) gilt:

:<math>U_a = U_{e2} \cdot \left (1 + \frac{R_6}{R_4}\right )</math>

Für den 2. Fall (invertierender Verstärker) gilt:

:<math>U_a = -U_{e1} \cdot \frac{R_6}{R_4}</math>

Der dritte Fall ist die Ansteuerung beider Eingänge:

:<math>U_a = -U_{e1} \cdot \frac{R_6}{R_4} + U_{e_2} \cdot \left (1 + \frac{R_6}{R_4}\right )</math>

Diese Schaltung ist gut für eine Erklärung, praktisch aber taugt sie nichts. Denn liegen an den Eingängen gleiche Spannungen an, ist die Ausgangsspannung nicht 0, wie eigentlich zu vermuten wäre. Deshalb ändern wir die Schaltung und fügen R7 ein. Jetzt stellt sich am Punkt + des OPs die Spannung

:<math>U_{e2+} = U_{e2} \cdot \frac{R_7}{R_5 + R_7}</math>

ein. Wenn wir das berücksichtigen, erhalten wir endlich einen richtigen Subtrahierer:

:<math>U_a = U_{e2} \cdot \left (1 + \frac{R_6}{R_4}\right ) \cdot \frac{R_7}{R_5 + R_7} - \frac{R_6}{R_4} \cdot U_{e1}</math>

Dies gilt für alle Subtrahierer, obwohl es natürlich auch hier wieder zwei Sonderfälle gibt; nämlich a) wenn alle Gegenkopplungswiderstände gleich sind:

:<math>R_6 = R_7 = R_4 = R_5</math>

dann ist

:<math>U_a = U_{e2} - U_{e1}</math>

oder b) wenn die Widerstandsverhältnisse gleich sind :

:<math>\frac{R_6}{R_4} = \frac{R_7}{R_5}</math>

Dann ergibt sich für Ua:

:<math>U_a = \left (U_{e2} \cdot \frac{R_7}{R_5}\right ) - \left (U_{e1} \cdot \frac{R_6}{R_4}\right )</math>

oder noch einfacher:

:<math>U_a = (U_{e2} - U_{e1}) \cdot \frac{R_6}{R_4}</math>

=== Addierer/Subtrahierer mit unterschiedlichen Faktoren ===
Legt man nicht den + sondern den - Eingang des Operationsverstärkers als Bezugspunkt zur Masse mit einem Widerstand fest, übernimmt der Vorwiderstand vom - Eingang, R4 die Aufgabe von R5.

[[Bild:Op-addsub.png]]

Hier die Schaltung die addieren und subtrahieren kann, mit unterschiedlichen Faktoren.
Sie kann verwendet werden für Aufgaben wie: Gesucht ist eine Schaltung, die aus 0...2.56 V eine Spannung von -10V...10V macht. Für dieses Beispiel wird hier die Dimensionierung durchgeführt:

{| class="wikitable" style="text-align: left"
|'''Ue1 = 5V'''
|Einfach festgelegt, muss nur ein positiver Wert sein
|-
|'''R6 = 200k'''
|Einfach festgelegt, könnte auch 100k oder 500k sein
|-
|Ue2i = 0V, '''Uai = -10V'''
|gewählter momentaner ''Zustand 1'', Ue2 = 0V ist günstig für Berechnung, Ua ist die dazupassende Ausgangsspannung
|-
|'''Ue2ii = 2.56V''', '''Uaii = 10V'''
|gewählter beliebiger ''Zustand 2''
|-
|Um = Ue2
|Gleichgewicht am Eingang
|-
|Ia + Ib = Ic
|In den Eingang fließt "kein" Strom
|-
|(Ua-Ue2)/R6 + (Ue1-Ue2)/R4 = Ue2/Rc
|Gleichung mit den Unbekannten R4 und Rc
|-
|(Uai-Ue2i)/R6 + (Ue1-Ue2i)/R4 = Ue2i/Rc
|Variablen für ''Zustand 1'' eingesetzt, bildet 1. Gleichung
|-
|(Uaii-Ue2ii)/R6 + (Ue1-Ue2ii)/R4 = Ue2ii/Rc
|Variablen für ''Zustand 2'' eingesetzt, bildet 2. Gleichung
|-
|<math>R4=-\frac{R6*U_{e1}}{U_{ai}}</math>
|2 Gleichungen mit 2 Unbekannten, Lösung durch Umformen der 1. Gleichung nach R4 und einsetzen von Ue2i=0 (freundlicherweise fällt die 2. Unbekannte dabei raus)
|-
|'''R4 = 100k'''
|restliche Werte eingesetzt
|-
|<math>Rc=\frac{R6*U_{e1}*U_{e2ii}}{U_{aii}*U_{e1}-U_{ai}*(U_{e1}-U_{e2ii})-U_{e1}*U_{e2ii}}</math>
|Ergebnis für R4 in die 2. Gleichung einsetzen und Umformen nach Rc
|-
|'''Rc = 41.6k'''
|Werte eingesetzt
|}

=== Der Instrumenten-Verstärker ===

[[Bild:Instrument.png]]

Ein Nachteil des Subtrahierer ist sein geringer Eingangswiderstand. Um den nahezu unendlichen Eingangswiderstand des verwendeten Operationsverstärkers zu erreichen, kann man einfach vor beide Eingänge je einen Impedanzwandler vorschalten.
Die hier beschriebene Schaltung ist um drei Widerstände erweitert und ermöglicht die Einstellung der Differenz-Verstärkung über nur einen Widerstand, nämlich R2.

Am invertierenden Eingang von IC1A gilt (Knotenregel):

:<math>\frac{U_{a1}-U_{e1}}{R_1}-\frac{U_{e1}-U_{e2}}{R_2}=0</math>

Am invertierenden Eingang von IC1C gilt (Knotenregel):

:<math>\frac{U_{a2}-U_{e2}}{R_1}+\frac{U_{e1}-U_{e2}}{R_2}=0</math>

Subtrahiert man die beiden Gleichungen voneinander, erhält man:

:<math>U_{a2}-U_{a1}=(U_{e2}-U_{e1})\cdot\left (1+\frac{2\cdot R_1}{R_2}\right )</math>

Letztere Differenz ist die Eingangsspannung eines normalen Subtrahierers mit der Verstärkung 1.

Also ergibt sich als Ausgangsspannung:

:<math>U_a=(U_{e2}-U_{e1}) \cdot \left (1+\frac{2\cdot R_1}{R_2}\right )</math>

Die Differenzverstärkung beträgt demnach:

:<math>V=\left (1+\frac{2\cdot R_1}{R_2} \right )</math>

Anwendung: Auswertung von Brückenschaltungen, wie Drucksensoren oder Dehnungsmessstreifen, die durch den Eingangswiderstand der Messschaltung nicht belastet werden dürfen. 
Instrumenten-Verstärker kann man auch fertig kaufen. Im INA102 ist die komplette Schaltung integriert. Für R2 sind 3 verschiedene Werte eingebaut, die bei passender Verschaltung eine Verstärkung von 1, 10, 100 oder 1000 ermöglichen.

=== Der Multiplizierer (Mischer) ===

=== Der Potentialdifferenzverstärker ===

[[Datei:Potentialdifferenzverstärker.png|400px]]

Der Potentialdifferenzverstärker ist eine OPV-Schaltung zum gewichteten Addieren und Subtrahieren beliebiger Spannungen.

Falls die Bedingung
<math>
\sum\frac{R_{0}}{R_{i}}=\sum\frac{R_{0}^{'}}{R_{i}^{'}}
</math>
erfüllt ist, vereinfacht sich der Term für die Ausgangsspannung zu folgendem Term:

<math>
U_{a}=\sum\frac{R_{0}^{'}}{R_{i}^{'}}U_{i}^{'}-\sum\frac{R_{0}}{R_{i}}U_{i}
</math>

=== Der Logarithmierer ===
Logarithmierer werden mit der Kennlinie einer Diode konstruiert, die einen eingeprägten Strom in eine Spannung übersetzt.

= Spannungsversorgung und Beschaltung =

== Betrieb mit einfacher Versorgungsspannung ==

Häufig möchte man Wechselspannung (z. B. Audiosignale) die auch negative Spannungen enthält mit einem Opamp verstärken, hat aber nur eine einfache Versorgungsspannung, eine positive in Bezug zu Masse, zur Verfügung. Dafür bieten sich folgende Schaltungen an, die in der Literatur leider häufig vernachlässigt werden.

=== Nichtinvertierender Verstärker ===

[[Bild: Ss_opamp1.png]]

Der positive Eingang wird mit einem Spannungsteiler (R3 und R5) auf die halbe Betriebsspannung gelegt. Dieser Spannung wird dann die zu verstärkende Eingangswechselspannung überlagert. Mit den Kondensatoren am Eingang (C1) und am Ausgang (C2) wird der Gleichspannungsanteil abgekoppelt.

Die Verstärkung ist in diesem Beispiel für Wechselspannung 11 (Formel wie oben), für Gleichspannung aber 1, da C4 für Gleichspannung einen unendlichen Widerstand darstellt. C3 sollte dorthin gehen, wo das Eingangssignal seinen Bezugspunkt hat, also die Abschirmung der Cinch-Buchse, während R5 dorthin geht, wo der Operationsverstärker seine negative Versorgungsspannung her bekommt, falls das nicht die gleichen Potentiale, hier GND, sein sollten.

=== Invertierender Verstärker ===

Das Prinzip funktioniert analog auch für die invertierende Beschaltung:

[[Bild: Ss_opamp2.png]]

= Kaufempfehlung =
LM 158/258/358 2 OPs in einem Gehäuse Preis ca. 0,30€.

Siehe auch [[Standardbauelemente#Operationsverst.C3.A4rker|Standardbauelemente - Operationsverstärker]].

Wer Audio OpAmps sucht - tangentsoft.net hat mal welche unter die Lupe genommen: [http://www.tangentsoft.net/audio/opamps.html Notes on Audio OpAmps]

= Weblinks =
*[http://www.eetkorea.com/ARTICLES/2003SEP/A/2003SEP19_AMD_AN07.PDF Op Amp Circuit Collection] - National Semiconductor Application Note 31 mit vielen weiteren OP-Schaltungen
*[http://www-s.ti.com/sc/psheets/slod006b/slod006b.pdf Op Amps for Everyone] - englischsprachiges, sehr umfangreiches Dokument zu OPV und deren Anwendung
* [http://www.elektronik-kompendium.de/sites/bau/0209092.htm Operationsverstärker im ElKo]
*[http://www.inf.fu-berlin.de/lehre/WS00/peg/folien/Peg_v7a.pdf OP Teil 1], [http://www.inf.fu-berlin.de/lehre/WS00/peg/folien/Peg_v7b.pdf OP Teil 2] - OP-Schaltungen (deutsch)
*[http://www.blecken.de/download/opverst.zip Schaltungstechnik mit Operationsverstärkern] - Prof. K. Blecken, Skript zur Vorlesung (deutsch, *.doc-Format)
* [http://www.roboternetz.de/wissen/index.php/Operationsverst%C3%A4rker RN-Wissen Operationsverstärker]
* [http://www.national.com/AU/design/0,4706,268_0_,00.html Online Seminar] von National Semiconductor
* [http://www.franzis.de/elo-das-magazin/grundlagen-und-ausbildung/operationsverstaerker/der-operationsverstaerker ELO-Online-Magazin, Franzis-Verlag], [http://www.franzis.de/online-shop/elektronik/lernpakete-elektronik/lernpaket-elektronik-mit-ics Lernpaket Elektronik mit ICs] "Elektronische Experimente mit integriertem Schaltkreis", Kasten mit Steckbrett/Bauelementen (ca. 40EUR),
* [[Schmitt-Trigger]]
* [[Aktiver RC-Bandpass|Aktiver RC-Bandpass auf Operationsverstärker-Basis]]
* [http://sound.westhost.com/appnotes/an001.htm Präzisionsgleichrichter], engl.
* [http://www.elektronikwissen.net/opamp/9-opamp-wissen.html OpAmp Praxis], Praktikertipps + schwingende Operationsverstärker in den Griff bekommen

[[Category:Grundlagen]]
[[Category:Bauteile]]

Operationsverstärker-Grundschaltungen

2014-09-29T13:02:33Z

Kbuchegg: /* Beispiel */

== Idealisiertes Modell eines OPV==

=== Anschlüsse ===
Ein Operationsverstärker hat zwei Eingänge (+) und (-) und einen Ausgang
(UA). Außerdem verfügt er über eine positive und eine negative
Spannungsversorgung (V+) und (V-).

=== Spannungsversorgungen ===
Die Spannungsversorgungen sollen zunächst nicht interessieren. Sie
werden in Schaltungen oft nicht eingezeichnet.
In der Praxis ist es jedoch wichtig zu wissen, dass die Ausgangsspannung immer zwischen (V+) und (V-) liegt. Die Ausgangsspannung des OPV kommt schließlich dadurch zustande, dass der Ausgang über einen Transistor mehr oder weniger hochohmig mit den beiden Versorgungsspannungen verbunden wird.

Wenn man einen OPV also mit +5V versorgt, so kann der OPV im besten Fall am Ausgang +5V erzeugen. Man würde in diesem Fall von einem "Rail-to-Rail" Operationsverstärker sprechen.
Bei vielen Operationsverstärkern ist die maximal mögliche Ausgangsspannung geringer als die Versorgungsspannung. Ein mit +5V Spannungsversorgung beschalteter OPV kann dann beispielsweise nur +4V Ausgangsspannung erzeugen.

| \
| \
-- | - \
| \_______
| /
-- | + /
| /
| /

=== Ausgang ===
Der Ausgang des OPV ist eine ideale Spannungsquelle. Das bedeutet, dass die
Ausgangsspannung unabhängig davon ist, was ausgangsseitig an den OPV
angeschlossen wird.
In der Praxis gilt dieses Modell häufig nur bei "sinnvollen Anwendungen". So ist beispielsweise der Ausgangsstrom des OPV nach oben begrenzt (typischerweise im mA-Bereich), und manche OPV schwingen sehr leicht, wenn man sie kapazitiv belastet.

=== Eingänge ===
Die Eingänge eines OPV sind hochohmig, d. h., es handelt sich nur um "Messfühler", die keinen Strom führen.
Achtung: Die Eingangsschutzbeschaltung (Dioden von GND und gegen VCC) bei manchen OPVs kann jedoch dazu führen, dass Strom in den Eingang fliesst, wenn dessen Betriebsspannung z.B. abgeschaltet ist.

=== Funktionsweise ===
Der OPV mißt zu jeder Zeit die Differenz <math>U_D = U(+) - U(-)</math> der
Eingangsspannungen.

Ist die Spannung an (+) größer als an (-), so erhöht der OPV die
Ausgangsspannung.
Ist die Spannung an (+) niedriger als an (-), so vermindert der OPV die
Ausgangsspannung.

Das Ergebnis dieses Vorgangs wird häufig über die Gleichung:

<math>U_a = v \cdot U_D</math>

beschrieben, wobei <math>v</math> eine sehr große Zahl (10^4...10^6) ist.

Mit Hilfe der beschriebenen Funktionsweise lassen sich alle grundlegenden Schaltungen herleiten.

=== Beispiel ===

Betrachtet wird die invertierende Grundschaltung nach Abbildung a) im Abschnitt [[Operationsverstärker-Grundschaltungen#Verstärkergrundschaltungen|Verstärkergrundschaltungen]].

[[Bild:Op-verstaerker-a.png]]

Für die Pfeilrichtungen der Spannungen und Ströme gilt:

<math>U_e</math>: von oben nach unten

<math>I_{R3}</math>: von links nach rechts

Die Spannung am (+)Eingang ist gleich Null. Die Spannung am (-)Eingang wird durch die Spannungsquelle <math>U_e</math> und durch die im OPV befindliche und mit dem Ausgang verbundene Spannungsquelle des OPV manipuliert.

* Ist die Spannung am (-)Eingang negativ, so erhöht der Operationsverstärker die Ausgangsspannung. Dadurch wird auch die Spannung am (-)Eingang positiver. Und zwar so lange, bis die Spannung am (-)Eingang gleich groß ist, wie die Spannung am (+)Eingang, also U(-)=0V.
* Ist die Spannung am (-)Eingang positiv, so vermindert der Operationsverstärker die Ausgangsspannung. Dadurch wird auch die Spannung am (-)Eingang negativer. Und zwar so lange, bis die Spannung am (-)Eingang gleich groß ist, wie die Spannung am (+)Eingang, also U(-)=0V.

Der Operationsverstärker wird also die Spannungen an (+) und (-)
angleichen. Das passiert immer dann, wenn der Ausgang mit dem (-)Eingang
verbunden ist. Man nennt das Prinzip "Gegenkopplung". Auf diese Art und
Weise funktionieren alle analogen OPV-Schaltungen.

Da an (+) Massepotential anliegt, wird somit auch (-) daran angeglichen, und so liegt an <math>R_3</math> die Spannung <math>U_e</math> an. Daher gilt:
<math>I_{R3}=\frac{U_e}{R_3}.</math>

Da der (-)Eingang hochohmig ist, fließt <math>I_{R3}</math> über <math>R_4</math> weiter zum OPV-Ausgang.

Ua ist die Spannung vom Ausgang zur (virtuellen) Masse am (-)Eingang.
(--> Pfeil einzeichnen und klarmachen, daß es egal ist, ob der Pfeil vom
Ausgang zur Masse geht oder vom Ausgang "entgegen der Stromrichtung" zur
virtuellen Masse an (-)!)

Mit Hilfe von <math>I_{R3}=\frac{U_e}{R_3}</math> ergibt sich:

<math>U_a = -R_4 \cdot I_{R3} = -{{R_4} \over {R_3}} \cdot U_e.</math>

Die Energie für den Stromtransport über <math>R_4</math> stammt vom OPV! Sobald die Ladungen ausgehend von der Spannungsquelle <math>U_e</math> die virtuelle Masse an (-) erreicht haben, hat <math>U_e</math> seine gesamte Energie abgegeben.

== Reale OPs / Kennwerte ==
Abweichend vom idealen OP besitzen reale OPs diverse Einschränkungen und Kennwerte, die sie für verschiedene Einsätze mehr oder weniger prädestinieren.

=== Leerlaufverstärkung ===
Die Leerlaufverstärkung gibt an, wie stark sich das Ausgangssignal i.A. der Änderung eines Eingangsignals statisch ändert, bzw nach dem Einschwingen erreichen könnte, wenn es nicht durch die Betriebsgrenzen limitiert wäre.

=== Verstärkungs-Bandbreiteprodukt ===
Das Verstärkungs-Bandbreiteprodukt gibt an, bei welcher Verstärkung welche Bandbreite erreicht werden kann. Durch Rückkopplung kann die Verstärkung eingestellt werden. Bei kleinerer Verstärkung ergibt sich somit eine höhere Bandbreite, wenn das Produkt aus beiden konstant ist. Die Bandbreite bei der Verstärkung eins heißt Transitfrequenz. Das Verstärkungs-Bandbreiteprodukt ist entscheidend für das Kleinsignalverhalten.

=== Anstiegszeit ===
Bestimmend für das Großsignalverhalten ist neben dem Verstärkungs-Bandbreiteprodukt die Anstiegszeit (slew rate), da bei hohen Ausgangsamplituden die Ausgangskurve eventuell zu steil wird, um richtig wiedergegeben zu werden.

=== Gleichtaktverstärkung ===
Infolge des inhomogenen Aufbaus der internen Verstärkerstufen werden die beiden Eingangssignale nicht exakt gleich verstärkt, was in einen Gleichanteil und einen Differenzanteil aufgeteilt werden kann. Der nicht erwünschte Gleichtakt (engl. ''common mode'') ist dabei ein Maß für die Qualität des OP.

== Verstärkergrundschaltungen ==
=== Grundbeschaltung mit Berechnung ===
[[Bild:Op-verstaerker-a.png]] [[Bild:Op-verstaerker-b.png]]

In a) und b) verwenden wir den OP als Verstärker und nutzen hier die Möglichkeit der Gegenkopplung, um definierte Verstärkungen zu erhalten. Wir gehen wieder davon aus, dass der OP ein ideales Bauteil ist und daher seine Leerlaufverstärkung unendlich ist. Ebenso betrachten wir den Eingangswiderstand als unendlich.

In '''a)''' ist ein invertierender Verstärker mit einem OP dargestellt. Durch die Widerstände R3 und R4 wird die Verstärkung bestimmt:

:<math>V = \frac{U_a}{U_e} = -\frac{R_4}{R_3}</math>

Das Verhältnis der beiden Widerstände bestimmt also die Verstärkung und somit die Ausgangsspannung:

:<math>U_a = -\frac{R_4}{R_3} \cdot U_e </math>

oder auch

:<math>U_a = V \cdot U_e</math>

Das negative Vorzeichen drückt aus, dass es sich um einen invertierenden Verstärker handelt.

Beim nichtinvertierenden Verstärker '''b)''' finden wir auch eine Rückkopplung über R6 zum invertierenden Eingang des OP. Die Verstärkung wird durch das Gegenkopplungsnetzwerk R6 und R7 bestimmt. Hier ist:

:<math>V = 1 + \frac{R6}{R7}</math>

Eine Verstärkung von 1 ist sinnvoll, wenn eingangsseitig eine Spannungsquelle mit hohem Innenwiderstand verwendet wird. Für <math>\frac{R6}{R7} \to 0</math> heißt die Schaltung "Spannungsfolger".

Kleinere Werte als 1 lassen sich nicht realisieren. Die Ausgangsspannung errechnet sich also so:

:<math>U_a = U_e \cdot \left (1 + \frac{R_6}{R_7}\right )</math>

Beispiel: Eine Eingangsspannung von 0,5 V soll auf den Wert 5 V verstärkt werden, es ist also eine Verstärkung V von 10 benötigt. R7 ist mit 10 kΩ vorgegeben. Also ist das Verhältnis

:<math>\frac{R_6}{R_7} = V - 1</math>

Bei einem Wert von 10 kΩ für R7 errechnet sich R6 zu

:<math>
R6 = (V - 1) \cdot R7
= (10 - 1) \cdot 10\,\mathrm{k\Omega}
= 90\,\mathrm{k\Omega}
</math>

Die Ausgangsspannung Ua wird also:

:<math>
U_a = U_e \cdot \left (1 + \frac{R_6}{R_7}\right )
= 0,5\,\mathrm{V} \cdot \left (1 + \frac{90\,\mathrm{k\Omega}}{10\,\mathrm{k\Omega}}\right)
= 5\,\mathrm{V}
</math>

=== Nichtinvertierender Verstärker mit Offset ===
Eine Abwandlung des nichtinvertierenden Verstärkers erlaubt es, einen konstanten Offset vorzugeben. D.h. von der zu verstärkenden Eingangsspannung U(e) wird eine konstante Spannung U(o) abgezogen und die Differenz verstärkt. Auf der Ausgangsspannung U(a) findet sich die Offsetspannung U(o) allerdings wieder.
[[Bild:Op-verstaerker-offset.png]]

Es gilt:

Offsetspannung:
:<math>
U_o = U_V \cdot \frac{R2}{R1 + R2}
</math>
mit U(V) = Versorgungsspannung an R1

Verstärkung:
:<math>
V = 1 + \frac{R3}{\frac{R1 \cdot R2}{R1 + R2}}
</math>

Ausgangsspannung:
:<math>
U_a = (U_e - U_o) \cdot V + U_o
</math>

Der Vorteil dieser Schaltung ist, daß nur die Differenz verstärkt wird. Damit kann eine größere Verstärkung gewählt werden. Zu berücksichtigen ist dabei, daß die Ausgangsspannung U(a) um die Offsetspannung U(o) überlagert ist.

=== Spannungsfolger (Impedanzwandler) ===

[[Bild:Op-spannungsfolger1.png]]

Eine Abart des nichtinvertierenden Verstärkers stellt der Spannungsfolger dar. Beim nichtinvertierenden Verstärker errechnet sich die Ausgangsspannung aus:

:<math>U_a = U_e \cdot \left (1 + \frac{R_2}{R_1}\right )</math>

Wenn wir R2 auf 0Ω (mit R1 > 0) oder R1 auf unendlich (mit R2 < ∞) ändern, erhalten wir daher:

:<math>V = 1 + \frac{R_2}{R_1} = 1</math>

Ein Spannungsfolger hat also eine Verstärkung V von 1.

Umgezeichnet sieht die Schaltung so aus:

[[Bild:Op-spannungsfolger2.png]]

Was soll das nun? Wir nutzen die Eigenschaft, dass ein idealer OP einen unendlichen Eingangswiderstand und einen Ausgangswiderstand von 0Ω hat. Real sieht das natürlich anders aus: so liegt der Eingangswiderstand Re bei normalen OPs in der Größenordnung von 1MOhm bis <math>10^{15} \Omega</math>, der Ausgangswiderstand Ra im Bereich 20Ω bis 1kOhm. Deshalb spricht man bei dieser Schaltung von einem Impedanzwandler. Eine solche Schaltung kann also aus einer relativ hochohmigen Spannungsquelle eine niederohmige, durch Folgeschaltungen belastbare Spannungsquelle machen.

[[Bild:Op-spannungsfolger3.png|left]]

In dem nebenstehenden Beispiel ist eine einfache Möglichkeit zur Erzeugung einer Referenzspannung gezeigt. Es kommt eine normale Stabilisierungsschaltung mit einer Zenerdiode zur Anwendung, die aber nicht mehr die schlechten Eigenschaften der Standardbeschaltung mit lediglich Widerstand und Zenerdiode hat. Bei einer Zenerdiode hängt die genaue Spannung davon ab, welcher Strom durch sie fliesst. Dieser Strom (und damit auch die Höhe der Zenerspannung) würde sich aber ändern, wenn ein Verbraucher die Zenerdiode direkt mit seinem Stromfluss belasten würde. Als Folge davon würde die Spannungslage der Zenerdiode je nach Verbraucher leicht schwanken. Durch den Spannungsfolger wird das verhindert, weil der jetzt den vom Verbraucher gezogenen Strom bereitstellt.

{{Clear}}

[[Bild:Op-spannungsfolger4.png|left]]

Eine weitere Anwendungsmöglichkeit wäre das hochohmige Auskoppeln einer Brückenspannung. Die Brückenschaltung selbst wird durch Folgeschaltungen nicht mehr belastet, alle anderen Eigenschaften bleiben erhalten.

{{Clear}}

=== Der Komparator ===

[[Bild:Op-komp-a.png]] [[Bild:Op-komp-b.png]]

In der einfachsten Beschaltung des Operationsverstärkers erhält man einen Komparator. Es fällt auf, dass kein Gegenkopplungsnetzwerk vorhanden ist. Der OP arbeitet daher mit seiner vollen Leerlaufverstärkung Vo. Dies bedeutet, dass bereits eine kleine Eingangsspannung genügt, um den OP in die Begrenzung zu treiben. Das heißt, die Ausgangsspannung Ua wird annähernd die Betriebsspannung erreichen.

Beim Komparator gibt es zwei Möglichkeiten der Beschaltung: die invertierende nach a) und die nichtinvertierende Beschaltung nach b).

'''Berechnungsbeispiel für Schaltung b)'''

Angenommen die Leerlaufverstärkung Vo von 40000 und eine Eingangsspannung von 0,1 Volt. Die Betriebsspannungen Vcc und Vee legen wir auf +/- 24 V fest. Damit ergibt sich theoretisch für Ua:

:<math>U_a = V_0 \cdot U_e = 40000 \cdot 0,1\,\mathrm{V} = 4000\,\mathrm{V}</math>

Das ist natürlich ein unrealistischer Wert, da Ua nicht höher sein kann als die Betriebsspannung. Also anders ausgedrückt: Bei welcher Spannung Ue erreicht der OP seine Aussteuerungsgrenze?

:<math>U_e = V_{cc} / V_0 = 24\,\mathrm{V} / 40000 = 0,6\,\mathrm{mV}</math>

Das bedeutet, dass eine Spannung von 0,6 mV ausreicht um den Komparator in die Begrenzung zu treiben.

Das gleiche gilt auch für den invertierenden Komparator, allerdings wird hier der OP in die negative Begrenzung gebracht.

:<math>-U_a = V_0 \cdot U_e</math>

So hat der Komparator nun einen einstellbaren Schaltpunkt.

[[Bild:Op-komp-c.PNG]]

=== Der Addierer (Summierverstärker) ===

[[Bild:Op-addierer.png]]

Ein als invertierender Verstärker beschalteter OP lässt sich so beschalten, dass ein Summensignal aus den Eingangsspannungen gebildet wird. Um die Funktion deutlich zu machen, ist eine Betrachtung der einzelnen Ströme nötig.

In einem invertierenden Verstärker wird sich die Ausgangsspannung immer so einstellen, dass der invertierende Eingang Massepotential hat. Die virtuelle Masse (VM) unterscheidet sich von einer "normalen" Masse dadurch, dass das Potential durch einen Regelungsvorgang zustande kommt.
An der virtuellen Masse (VM) gilt die Knotenpunktregel, wonach die Summe der zufließenden Ströme gleich der Summe der abfließenden Ströme ist.

:<math>I_1 + I_2 = -I_3</math>

Sofern <math>U_{e1}</math> und <math>U_{e2}</math> bekannt sind, lässt sich die Gleichung umformen in:

:<math>\frac{U_{e1}}{R_1} + \frac{U_{e2}}{R_2} = -\frac{U_a}{R_3}</math>

Nach Ua aufgelöst ergibt sich:

:<math>-U_a = \left (U_{e1} \cdot \frac{R_3}{R_1}\right ) + \left (U_{e2} \cdot \frac{R_3}{R_2}\right ) + ... + \left (U_{en} \cdot \frac{R_3}{R_n}\right )</math>

Einen Sonderfall gibt es, wenn die Widerstände R1 und R2 gleich sind. Dann gilt

:<math>R_1 = R_2 = R_x</math>

und damit

:<math>-U_a = \frac{R_3}{R_x} \cdot (U_{e1} + U_{e2})</math>.

=== Der Subtrahierer (Differenzverstärker) ===

[[Bild:Op-subtrahierer.png]]

Ein Subtrahierer ist die Zusammenschaltung eines invertierenden und eines nichtinvertierenden Verstärkers. Schliessen wir Punkt Ue1 nach Masse kurz und steuern Ue2 an, arbeitet die Schaltung als nichtinvertierender Verstärker. Wird Ue2 nach Masse verbunden und Ue1 angesteuert, verhält sich die Schaltung als invertierender Verstärker (R7 vorerst nicht beachten).

Für den 1. Fall (nichtinvertierender Verstärker) gilt:

:<math>U_a = U_{e2} \cdot \left (1 + \frac{R_6}{R_4}\right )</math>

Für den 2. Fall (invertierender Verstärker) gilt:

:<math>U_a = -U_{e1} \cdot \frac{R_6}{R_4}</math>

Der dritte Fall ist die Ansteuerung beider Eingänge:

:<math>U_a = -U_{e1} \cdot \frac{R_6}{R_4} + U_{e_2} \cdot \left (1 + \frac{R_6}{R_4}\right )</math>

Diese Schaltung ist gut für eine Erklärung, praktisch aber taugt sie nichts. Denn liegen an den Eingängen gleiche Spannungen an, ist die Ausgangsspannung nicht 0, wie eigentlich zu vermuten wäre. Deshalb ändern wir die Schaltung und fügen R7 ein. Jetzt stellt sich am Punkt + des OPs die Spannung

:<math>U_{e2+} = U_{e2} \cdot \frac{R_7}{R_5 + R_7}</math>

ein. Wenn wir das berücksichtigen, erhalten wir endlich einen richtigen Subtrahierer:

:<math>U_a = U_{e2} \cdot \left (1 + \frac{R_6}{R_4}\right ) \cdot \frac{R_7}{R_5 + R_7} - \frac{R_6}{R_4} \cdot U_{e1}</math>

Dies gilt für alle Subtrahierer, obwohl es natürlich auch hier wieder zwei Sonderfälle gibt; nämlich a) wenn alle Gegenkopplungswiderstände gleich sind:

:<math>R_6 = R_7 = R_4 = R_5</math>

dann ist

:<math>U_a = U_{e2} - U_{e1}</math>

oder b) wenn die Widerstandsverhältnisse gleich sind :

:<math>\frac{R_6}{R_4} = \frac{R_7}{R_5}</math>

Dann ergibt sich für Ua:

:<math>U_a = \left (U_{e2} \cdot \frac{R_7}{R_5}\right ) - \left (U_{e1} \cdot \frac{R_6}{R_4}\right )</math>

oder noch einfacher:

:<math>U_a = (U_{e2} - U_{e1}) \cdot \frac{R_6}{R_4}</math>

=== Addierer/Subtrahierer mit unterschiedlichen Faktoren ===
Legt man nicht den + sondern den - Eingang des Operationsverstärkers als Bezugspunkt zur Masse mit einem Widerstand fest, übernimmt der Vorwiderstand vom - Eingang, R4 die Aufgabe von R5.

[[Bild:Op-addsub.png]]

Hier die Schaltung die addieren und subtrahieren kann, mit unterschiedlichen Faktoren.
Sie kann verwendet werden für Aufgaben wie: Gesucht ist eine Schaltung, die aus 0...2.56 V eine Spannung von -10V...10V macht. Für dieses Beispiel wird hier die Dimensionierung durchgeführt:

{| class="wikitable" style="text-align: left"
|'''Ue1 = 5V'''
|Einfach festgelegt, muss nur ein positiver Wert sein
|-
|'''R6 = 200k'''
|Einfach festgelegt, könnte auch 100k oder 500k sein
|-
|Ue2i = 0V, '''Uai = -10V'''
|gewählter momentaner ''Zustand 1'', Ue2 = 0V ist günstig für Berechnung, Ua ist die dazupassende Ausgangsspannung
|-
|'''Ue2ii = 2.56V''', '''Uaii = 10V'''
|gewählter beliebiger ''Zustand 2''
|-
|Um = Ue2
|Gleichgewicht am Eingang
|-
|Ia + Ib = Ic
|In den Eingang fließt "kein" Strom
|-
|(Ua-Ue2)/R6 + (Ue1-Ue2)/R4 = Ue2/Rc
|Gleichung mit den Unbekannten R4 und Rc
|-
|(Uai-Ue2i)/R6 + (Ue1-Ue2i)/R4 = Ue2i/Rc
|Variablen für ''Zustand 1'' eingesetzt, bildet 1. Gleichung
|-
|(Uaii-Ue2ii)/R6 + (Ue1-Ue2ii)/R4 = Ue2ii/Rc
|Variablen für ''Zustand 2'' eingesetzt, bildet 2. Gleichung
|-
|<math>R4=-\frac{R6*U_{e1}}{U_{ai}}</math>
|2 Gleichungen mit 2 Unbekannten, Lösung durch Umformen der 1. Gleichung nach R4 und einsetzen von Ue2i=0 (freundlicherweise fällt die 2. Unbekannte dabei raus)
|-
|'''R4 = 100k'''
|restliche Werte eingesetzt
|-
|<math>Rc=\frac{R6*U_{e1}*U_{e2ii}}{U_{aii}*U_{e1}-U_{ai}*(U_{e1}-U_{e2ii})-U_{e1}*U_{e2ii}}</math>
|Ergebnis für R4 in die 2. Gleichung einsetzen und Umformen nach Rc
|-
|'''Rc = 41.6k'''
|Werte eingesetzt
|}

=== Der Instrumenten-Verstärker ===

[[Bild:Instrument.png]]

Ein Nachteil des Subtrahierer ist sein geringer Eingangswiderstand. Um den nahezu unendlichen Eingangswiderstand des verwendeten Operationsverstärkers zu erreichen, kann man einfach vor beide Eingänge je einen Impedanzwandler vorschalten.
Die hier beschriebene Schaltung ist um drei Widerstände erweitert und ermöglicht die Einstellung der Differenz-Verstärkung über nur einen Widerstand, nämlich R2.

Am invertierenden Eingang von IC1A gilt (Knotenregel):

:<math>\frac{U_{a1}-U_{e1}}{R_1}-\frac{U_{e1}-U_{e2}}{R_2}=0</math>

Am invertierenden Eingang von IC1C gilt (Knotenregel):

:<math>\frac{U_{a2}-U_{e2}}{R_1}+\frac{U_{e1}-U_{e2}}{R_2}=0</math>

Subtrahiert man die beiden Gleichungen voneinander, erhält man:

:<math>U_{a2}-U_{a1}=(U_{e2}-U_{e1})\cdot\left (1+\frac{2\cdot R_1}{R_2}\right )</math>

Letztere Differenz ist die Eingangsspannung eines normalen Subtrahierers mit der Verstärkung 1.

Also ergibt sich als Ausgangsspannung:

:<math>U_a=(U_{e2}-U_{e1}) \cdot \left (1+\frac{2\cdot R_1}{R_2}\right )</math>

Die Differenzverstärkung beträgt demnach:

:<math>V=\left (1+\frac{2\cdot R_1}{R_2} \right )</math>

Anwendung: Auswertung von Brückenschaltungen, wie Drucksensoren oder Dehnungsmessstreifen, die durch den Eingangswiderstand der Messschaltung nicht belastet werden dürfen. 
Instrumenten-Verstärker kann man auch fertig kaufen. Im INA102 ist die komplette Schaltung integriert. Für R2 sind 3 verschiedene Werte eingebaut, die bei passender Verschaltung eine Verstärkung von 1, 10, 100 oder 1000 ermöglichen.

=== Der Multiplizierer (Mischer) ===

=== Der Potentialdifferenzverstärker ===

[[Datei:Potentialdifferenzverstärker.png|400px]]

Der Potentialdifferenzverstärker ist eine OPV-Schaltung zum gewichteten Addieren und Subtrahieren beliebiger Spannungen.

Falls die Bedingung
<math>
\sum\frac{R_{0}}{R_{i}}=\sum\frac{R_{0}^{'}}{R_{i}^{'}}
</math>
erfüllt ist, vereinfacht sich der Term für die Ausgangsspannung zu folgendem Term:

<math>
U_{a}=\sum\frac{R_{0}^{'}}{R_{i}^{'}}U_{i}^{'}-\sum\frac{R_{0}}{R_{i}}U_{i}
</math>

=== Der Logarithmierer ===
Logarithmierer werden mit der Kennlinie einer Diode konstruiert, die einen eingeprägten Strom in eine Spannung übersetzt.

= Spannungsversorgung und Beschaltung =

== Betrieb mit einfacher Versorgungsspannung ==

Häufig möchte man Wechselspannung (z. B. Audiosignale) die auch negative Spannungen enthält mit einem Opamp verstärken, hat aber nur eine einfache Versorgungsspannung, eine positive in Bezug zu Masse, zur Verfügung. Dafür bieten sich folgende Schaltungen an, die in der Literatur leider häufig vernachlässigt werden.

=== Nichtinvertierender Verstärker ===

[[Bild: Ss_opamp1.png]]

Der positive Eingang wird mit einem Spannungsteiler (R3 und R5) auf die halbe Betriebsspannung gelegt. Dieser Spannung wird dann die zu verstärkende Eingangswechselspannung überlagert. Mit den Kondensatoren am Eingang (C1) und am Ausgang (C2) wird der Gleichspannungsanteil abgekoppelt.

Die Verstärkung ist in diesem Beispiel für Wechselspannung 11 (Formel wie oben), für Gleichspannung aber 1, da C4 für Gleichspannung einen unendlichen Widerstand darstellt. C3 sollte dorthin gehen, wo das Eingangssignal seinen Bezugspunkt hat, also die Abschirmung der Cinch-Buchse, während R5 dorthin geht, wo der Operationsverstärker seine negative Versorgungsspannung her bekommt, falls das nicht die gleichen Potentiale, hier GND, sein sollten.

=== Invertierender Verstärker ===

Das Prinzip funktioniert analog auch für die invertierende Beschaltung:

[[Bild: Ss_opamp2.png]]

= Kaufempfehlung =
LM 158/258/358 2 OPs in einem Gehäuse Preis ca. 0,30€.

Siehe auch [[Standardbauelemente#Operationsverst.C3.A4rker|Standardbauelemente - Operationsverstärker]].

Wer Audio OpAmps sucht - tangentsoft.net hat mal welche unter die Lupe genommen: [http://www.tangentsoft.net/audio/opamps.html Notes on Audio OpAmps]

= Weblinks =
*[http://www.eetkorea.com/ARTICLES/2003SEP/A/2003SEP19_AMD_AN07.PDF Op Amp Circuit Collection] - National Semiconductor Application Note 31 mit vielen weiteren OP-Schaltungen
*[http://www-s.ti.com/sc/psheets/slod006b/slod006b.pdf Op Amps for Everyone] - englischsprachiges, sehr umfangreiches Dokument zu OPV und deren Anwendung
* [http://www.elektronik-kompendium.de/sites/bau/0209092.htm Operationsverstärker im ElKo]
*[http://www.inf.fu-berlin.de/lehre/WS00/peg/folien/Peg_v7a.pdf OP Teil 1], [http://www.inf.fu-berlin.de/lehre/WS00/peg/folien/Peg_v7b.pdf OP Teil 2] - OP-Schaltungen (deutsch)
*[http://www.blecken.de/download/opverst.zip Schaltungstechnik mit Operationsverstärkern] - Prof. K. Blecken, Skript zur Vorlesung (deutsch, *.doc-Format)
* [http://www.roboternetz.de/wissen/index.php/Operationsverst%C3%A4rker RN-Wissen Operationsverstärker]
* [http://www.national.com/AU/design/0,4706,268_0_,00.html Online Seminar] von National Semiconductor
* [http://www.franzis.de/elo-das-magazin/grundlagen-und-ausbildung/operationsverstaerker/der-operationsverstaerker ELO-Online-Magazin, Franzis-Verlag], [http://www.franzis.de/online-shop/elektronik/lernpakete-elektronik/lernpaket-elektronik-mit-ics Lernpaket Elektronik mit ICs] "Elektronische Experimente mit integriertem Schaltkreis", Kasten mit Steckbrett/Bauelementen (ca. 40EUR),
* [[Schmitt-Trigger]]
* [[Aktiver RC-Bandpass|Aktiver RC-Bandpass auf Operationsverstärker-Basis]]
* [http://sound.westhost.com/appnotes/an001.htm Präzisionsgleichrichter], engl.
* [http://www.elektronikwissen.net/opamp/9-opamp-wissen.html OpAmp Praxis], Praktikertipps + schwingende Operationsverstärker in den Griff bekommen

[[Category:Grundlagen]]
[[Category:Bauteile]]

Snippets

2014-07-15T16:52:14Z

Kbuchegg: /* AVR: ADC */

Auf dieser Seite können kleine, oft verwendbare Quelltextchen und Designideen (Snippets) abgelegt und abgerufen werden.

Bitte die Snippets universell verwendbar halten und für Dritte ausführlich und verständlich kommentieren.

== Software-Snippets ==

=== AVR: ADC ===

Die folgenden Routinen sind einfachste C-Funktionen zum Auslesen des [[AD-Wandler]]s eines AVR. Die Registernamen bitte an den konkret verwendeten AVR anpassen (Datenblatt).

Anm.: Umfangreichere Routinen mit Mittelwertbildung usw. finden sich im [[AVR-GCC-Tutorial#Analoge_Ein-_und_Ausgabe|AVR-GCC-Tutorial: Analoge Ein- und Ausgabe]].

'''Auslesen eines Analogports'''

<syntaxhighlight lang="c">
// Führt eine AD Konversion durch und
// liefert den Wert (0-1023) von PORT ADC(src) zurück

uint16_t ReadValue(uint8_t src)
{
ADMUX = src;
ADCSR = _BV(ADEN) | _BV(ADSC) | _BV(ADPS2);
while (bit_is_set (ADCSR, ADSC))
;
return ADC;
}
</syntaxhighlight>

Anmerkungen:
* ADMUX Parameter siehe Datenblatt (nicht gleich "Pinnummer")
* ADSC/ADEN/ADPS2 Parameter siehe Datenblatt
* Einstellung der Referenzspannung beachten (Intern/Extern)
* Wandlerfrequenz an Genauigkeitsansprüche anpassen und nach Empfehlungen des Datenblatts in abh. vom "Haupttakt" einstellen
* ADEN nach erstmaligem Einschalten redundant
* evtl. Dummy Readout durchfuehren

''' Umrechnung Wandlungsergebnis in gemessene Spannung'''

<syntaxhighlight lang="c">
// Liefert die am ADC anliegende Spannung in mV zurück
#define ADC_CONV_CONST 5000/1024 // Spannung pro LSB (10 bit Wandler)
#define ADC_CORR_VAL (ADC*8)/9 // bei 5V Ref-Spannung erhält man mit dieser korrektur 5001mV bei einem ADC-Wert von 1023!
// Für eine fehlerfreie Umwandlung ist eine Referenz von z.b 4.096V oder 2.56V notwendig...
uint16_t ReadValue(uint8_t src) {
ADMUX = src;
ADCSR = _BV(ADEN) | _BV(ADSC) | _BV(ADPS2);

while (bit_is_set (ADCSR, ADSC))
;

return ADC*ADC_CONV_CONST+ADC_CORR_VAL;
}
</syntaxhighlight>

== Hardware-Snippets ==

=== Wie schließe ich ein "LC-Display" an einen Mikrocontroller an? ===

Siehe [[AVR-GCC-Tutorial#Ansteuerung_eines_LCD|AVR-GCC-Tutorial: Ansteuerung eines LCD]] und [[LCD]].

===Wie schließe ich einen MOSFET an einen Mikrocontroller an?===

In folgenden sind keine konkreten Typen für die MOS[[FET]]s genannt. Typen findet man in der [[Mosfet-Übersicht]] und in den parametrischen Suchmaschinen der Hersteller. Die genauen Daten und Belastungsgrenzen sind dann aus den Datenblättern zu entnehmen und für die geplante Schaltung zu prüfen.

==> * [[FET]]

==> * [[Treiber]]

====Direkte Methode: N-Kanal MOSFET (NFET)====

<pre>
(VCC)
|
(Last)
|
|
(Drain )
(Port µC) -----(Gate )
(Source)
|
|
(GND)
</pre>

Ausschlaggebend für die Steuerung ist die Gate-Source-Spannung. In dieser einfachen Schaltung ist das also die Spannung am Port des µC minus die Spannung an Source (= GND = 0V). Diese Spannung ist positiv!
Wenn diese einen Schwellwert überschreitet, dann sinkt der Drain-Source-Widerstand (RDSon)schlagartig auf ein Minimum. Übliche Werte liegen bei 0.1Ω, dieser Widerstand ist aber von dem Drain-Source-Strom und der Gate-Source-Spannung abhängig.
Der Umschaltpunkt (Spannung und Widerstand) kann im Datenblatt in den "RDSon vs. VGS" Diagramm abgelesen werden.

====Direkte Methode: P-Kanal MOSFETs (PFET)====

<pre>
(VCC)
|
|
(Source)
(Port µC) -----(Gate )
(Drain )
|
|
(Last)
|
(GND)
</pre>

Ausschlaggebend für die Steuerung ist die Gate-Source-Spannung. In dieser einfachen Schaltung ist das also die Spannung am Port des µC minus die Spannung an Source (= VCC). Diese Spannung ist negativ!
Wenn diese einen Schwellwert unterschreitet, dann sinkt der Drain-Source-Widerstand (RDSon)schlagartig auf ein Minimum. Übliche Werte liegen bei 0.1Ω, dieser Widerstand ist aber von dem Drain-Source-Strom und der Gate-Source-Spannung abhängig.
Der Umschaltpunkt (Spannung und Widerstand) kann im Datenblatt in den "RDSon vs. VGS" Diagramm abgelesen werden.

'''Anmerkungen'''

Zu beachten ist, dass zwischen Gate und Source und zwischen Gate und Drain eine Kapazität existiert, welche bei jedem Umschalt-Vorgang umgeladen werden muss. Besonders bei höheren Frequenzen (> 10kHz) ist zur Strombegrenzung zwischen Gate und Port-Pin ein Widerstand sinnvoll. Übliche Werte dafür sind 50 - 100Ω. Je höher der Widerstand ist, desto länger dauert das Umladen des Kondensators und desto langsamer schaltet der Transistor um. Daraus ergibt sich eine höhere Verlustleistung im Transistor, was unter Umständen zur Zerstörung des Transistors führen kann.

TODO: Pinbelegung eines typischen MOSFETS

====Indirekte Methode: Ansteuerungen mit Push-Pull-Transistoren====

<pre>
12V------------------------o------o---------------o-------------
| | |
| | |
.-. | |
| |2k2 | |
| |R2 | |
'-' |T2 |
| |BC338 |
| |/ |
o----| |
| |> P-FET |
| | ___ IRF4905|
o---|<-o---|___|----||-+
.---------. | 1N4148 R3 10R ||->
| | | ||-+
| | ___ |/ |
| |---|___|-----| T1 o---------
| | R1 2k2 |> BC338 | |
| µC | | .-. |
| | | | | |
| | | | | Last - 1N5819
| | | '-' ^
'---------' | | |
| | |
GND------------------------o----------------------o---------o---
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
</pre>

Durch die beiden NPN Treibertransistoren T1 & T2 (http://www.mikrocontroller.net/part/BC338) wird das Gate des P-FET auf HIGH oder LOW gezogen.
Wenn die Basis von T1 auf LOW ist dann wird die Basis von T2 auf HIGH gezogen.
Der P-FET kann natürlich auch einfach gegen einen N-FET Ausgetauscht werden, wenn man die Last zwischen +12V und Drain Schaltet.
Mit dieser Schaltung kann man einen FET mit 20kHz und mehr (laut Simulation sind auch 50kHz kein Problem) ansteuern.
Der Strom, welcher in das Gate rein bzw. raus fliesst, kann man mit R3 begrenzt werden.
Die geschaltete Betriebsspannung darf die zulässige Gate-Source Spannung (meist 20V) bei dieser Schaltung nicht überschreiten.

Im µC Bereich können desweiteren folgende Hinweise gegeben werden:

* Es sollten sog. "Logik-Level" MOSFETS verwendet werden (Vth < 2V)
* Die Schaltleistung des FETs muss beachtet werden (Ids, VBrss)
* Beim Schalten von induktiven Lasten wie Relais, Motoren, oder auch Lasten über eine längere Zuleitung, sollten [[Relais_mit_Logik_ansteuern#Freilaufdiode|Freilaufdioden]] verwendet werden (im Schaltplan die Schottkydiode 1N5819 in Sperrrichtung über der Last.) Normale 1N400x Dioden sind zu langsam.

[[Kategorie:Algorithmen und Arithmetik]]

FAQ

2013-12-13T11:07:50Z

Kbuchegg: Fragezeichen entfernt, um einfache Verlinkung aus Threads zu ermöglichen

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

itoa() ist keine C-Standardfunktion (wohl aber ihre Umkehrung atoi() ). Auf manchen Compilern heisst diese Funktion dann folgerichtig _itoa(), wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Library [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

itoa( i, Buffer, 10 ); - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array Buffer groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei printf() (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

Typ ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
c char
d int
f float, double
ld long
u unsigned int
lu unsigned long
p pointer
s string
x ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
X ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

+ Vorzeichen wird immer ausgegeben
- Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
0 anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Wertebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man itoa() nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j 

Das Grundprinzip ist einfach: 
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> 2
8392 / 10 -> 839

839 % 10 -> 9
839 / 10 -> 83

83 % 10 -> 3
83 / 10 -> 8

8 % 10 -> 8
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j 

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit einen Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

Präprozessordefinitionen besitzen keine eigene Datentypen, da sie eine reine Textersetzungen durchführen. Deren Inhalte können aber ggf. zu Werten aufgelöst werden, die datentypbehaftet sind.

=Aktivieren der Floating Point Version von sprintf bei WinAVR bzw AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries'' In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous'' In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File - wie geht das =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen. Für dieses System soll eine Aufteilung erfolgen, so dass funtionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionIntA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SettingB 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur eine Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. CTC Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte TOP). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

C-Präprozessor

2013-11-25T16:07:00Z

Kbuchegg: /* #define */

Der erste Verarbeitungsschritt bei der Kompilierung eines [[C]]/[[C++]]-Programmes erfolgt durch den '''Präprozessor'''. Dieser verändert den Quelltext, den die späteren Verarbeitungsphasen erhalten, in folgender Hinsicht:
* Einbeziehen zusätzlicher Dateien ([[Include-Files]])
* Ersetzen von (parametrisierbaren) [[Makro]]s
* Entfernen einzelner Abschnitte (= bedingte Kompilierung)

Im Grunde kann man sich den Präprozessor als eine Art Texteditor vorstellen, der die Anweisungen, was er zu tun hat, dem Text entnimmt, den er bearbeitet. In jedem Texteditor gibt es zb. die Funktion 'Suchen und Ersetzen'. Auch im Präprozessor gibt es sie, nur heißt sie dort #define. Alle Anweisungen an den Präprozessor beginnen grundsätzlich damit, daß das Zeichen '#' das erste Zeichen in einer Textzeile darstellt. Und umgekehrt: Ist das erste Zeichen in einer Textzeile ein '#', so handelt es sich um eine Präprozessor-Anweisung.

==#include==
Die #include weist den Präprozessor an, den Inhalt der angegebenen Datei anstelle der #include Anweisung einzusetzen. Weiter passiert nichts. Bei der Angabe des Dateinamens der einzusetzenden Datei gibt es 2 Formen
<syntaxhighlight lang="c">
#include "Datei1.xyz"
#include <Datei2.abc>
</syntaxhighlight>
Der Unterschied zwischen beiden Formen besteht rein im Aufsuchpfad, den der Präprozessor benutzt, um die Datei zu finden. Per Konvention wird die < >-Form benutzt, um systemweite Includes durchzuführen. Alle mit dem Compiler mitgelieferten Header Files sind zb. solche systemweite-Includes. Bei der Installation des Compilers wurde im System hinterlassen, auf welchem Pfad sie gefunden werden können. Durch Verwendung der < >-Form wird dem Präprozessor mitgeteilt, dass diese damals vereinbarten Pfadangaben zur Aufsuche dieser Datei benutzt werden soll.

==#define==
Mittels #define wird eine Textersetzung vereinbart.
<syntaxhighlight lang="c">
#define ABC xyz
</syntaxhighlight>
weist den Präprozessor an, im weiteren Quelltext alle Vorkommen von 'ABC' durch den Text 'xyz' zu ersetzen. Der Präprozessor macht dies überall, solange
* es sich an der zu ersetzenden Stelle um keinen String handelt. Mit obigem #define würde also in "Dies ist ABC" keine Textersetzung stattfinden.
* er den Ursprungstext als 'Wort' im Sinne eines C-Wortes handelt. Mit obigem #define würde also in cdABCef = 5; keine Textersetzung stattfinden.

Wichtig ist: Der Präprozessor führt eine reine Textersetzung durch! Ob sich durch diese Ersetzung eine Logikänderung im Programm ergibt, interessiert den Präprozessor nicht.

<syntaxhighlight lang="c">
#define NR 5

int Werte[NR];

...

for( i = 0; i < NR; i )
printf( "%d", Werte[i] );
</syntaxhighlight>

Bevor der eigentliche Compiler den Quelltext zu Gesicht bekommt, wird er zunächst vom Präprozessor bearbeitet. Dieser führt die Textersetzung durch, indem er alle Vorkommen von NR durch den Text 5 ersetzt. Erst dieses Ergebnis

<syntaxhighlight lang="c">
int Werte[5];

...

for( i = 0; i < 5; i )
printf( "%d", Werte[i] );
</syntaxhighlight>

wird dann dem eigentlichen Compiler zur Übersetzung vorgelegt. In diesem Beispiel hat man durch den Einsatz des Präprozessors erreicht, dass die Anzahl der Arrayelemente immer mit dem Maximalwert in der for-Schleife übereinstimmt. Ein Fehler, dass beispielweise die Arraygröße verändert wird, ohne das die for-Schleife angepasst würde, ist durch den Einsatz des Präprozessors wirkungsvoll verhindert worden.

Aber auch hier wieder: Der Präprozessors macht nur eine Textersetzung! Für den Präprozessors ist es völlig unerheblich, ob sich dadurch die Logik des Programms aus Sicht des Programmierers verändert
<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*PART;
</syntaxhighlight>
In diesem Beispiel mag es schon so sein, dass der Programmierer im Sinn hatte, den Ausdruck 4 mal 8 berechnen zu lassen, wobei sich die 8 durch eine Addition von 3 und 5 ergeben. Das interessiert aber den Präprozessor nicht. Der macht eine reine textuelle Ersetzung, indem er den Text 'PART' durch den Text '3+5' austauscht, wodurch dieses Ergebnis entsteht

<syntaxhighlight lang="c">
#define PART 3+5

...

y = 4*3+5;
</syntaxhighlight>
Dies ist aber etwas anderes, nämlich '(4*3)+5', also ursprünglich beabsichtigt war, nämlich '4*(3+5)'.

Schlussfolgerung: Es ist bei komplexeren Makros nicht ungewöhnlich, dass sich in Makros relativ viele Klammern wiederfinden, deren Zweck gerade für einen Neuling nicht auf den ersten Blick zu durchschauen ist.
<syntaxhighlight lang="c">
#define PART (3+5)

...
x = PART;
y = 4*PART;
</syntaxhighlight>
Während die Klammern im Makro bei der Zuweisung an x keine Funktion erfüllen (aber auch nicht störend sind), sind sie bei der Zuweisung an y lebenswichtig um der ganzen Anweisung nach der Textersetzung die beabsichtigte Bedeutung zu geben.

==#if, #ifdef==

==mögliche Probleme beim Einsatz des Präprozessors==
Eine am C-Präprozessor häufig geäußerte Kritik ist, dass er (nahezu) ohne Berücksichtigung der eigentlichen Sprachsyntax arbeitet ("The C-Preprocessor doesn't know about C"). Die Tatsache, dass Makros beispielsweise auf der Basis von Textersatz arbeiten, kann zu Überaschungen führen. So wird in
<syntaxhighlight lang="c">
#define cub(a) a*a*a
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
in x nicht etwa der Wert 125 (5 hoch 3) stehen, sondern der Wert 13, da nach Ersetzen des Makros der folgende Quelltext kompiliert wird ...
<syntaxhighlight lang="c">
x = y+1*y+1*y+1;
</syntaxhighlight>
... und durch die arithmetischen Vorrangregeln, wird dieser Ausdruck so ausgewertet:

<syntaxhighlight lang="c">
x = y + (1*y) + (1*y) + 1;
</syntaxhighlight>

Deshalb sollte man jeden Parameter eines Makros bei jeder Verwendung klammern. Damit werden viele Probleme mit Makros gelöst und man erhält für obiges Beispiel folgende Form und damit auch eine korrekte Berechnung:
<syntaxhighlight lang="c">
#define cub(a) ((a)*(a)*(a))
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
Ein weiteres Problem besteht jedoch, wenn ein Makro-Parameter im Ersatztext doppelt verwendet wird:
<syntaxhighlight lang="c">
#define max(a, b) ((a>b) ? (a) : (b))
...
int x, y;
...
x = max(y, 10); /* OK */
x = max(++y, 10); /* ?? */
</syntaxhighlight>
Im zweiten Fall wird die Variable ''y'' u.U. ''zweimal'' inkrementiert - was ohne Kenntnis der Makro-Definition keineswegs offensichtlich ist (''max'' könnte auch eine echte Funktion sein).

Die Tatsache, dass der C-Präprozessor die Syntax von C/C++ nicht wirklich berücksichtigt, ist allerdings auch nützlich. So lassen sich mit dem C-Präprozessor Datentypen parametrisieren, um systematische Programmteile zu vereinfachen:
<syntaxhighlight lang="c">
/* GSAWP:
generiert Funktionsdefinition zum Vertauschen des Inhalts von zwei Variablen
*/
#define GSWAP(n, T)s\
void n(T *xp, T *yp) { T tmp = *xp; *xp = *yp; *yp = tmp; }
...
GSWAP(iswap, int)
GSWAP(dswap, double)
GSWAP(swap_s, struct s)
...
int a, b;
double c, d;
struct s e, f;
...
iswap(&a, &b);
dswap(&c, &d);
swap_s(&e. &f);
</syntaxhighlight>

Viele typische Anwendungsfälle des Präprozessors lassen sich allerdings bereits mit Standard-C-Bordmitteln erfolgreich erschlagen:
* Statt ''#define'' besser mit ''const'' vereinbarte Variablen benutzen. Bei jedem besseren Compiler ergeben sich dank Optimierung keinerlei Nachteile.
* ''enum'' für Konstantenfelder benutzen. Dabei sollte man allerdings sauber casten, da ''enum''-Werte in der Regel als ''int'' interpretiert werden.
* Neuere Versionen des GCC unterstützen ''inline'', wodurch Makros für Einzeiler überflüssig werden.

In [[C++]] wurden ergänzend zum C-Präprozessor weitere Mechanismen eingeführt. So erlauben [[Templates (C++)|Templates]] generische Programmierung, womit viele der "Makro-Tricks" wie die obigen überflüssig werden.

[[Kategorie:C]]

C-Präprozessor

2013-11-25T16:05:41Z

Kbuchegg: /* #define */

Der erste Verarbeitungsschritt bei der Kompilierung eines [[C]]/[[C++]]-Programmes erfolgt durch den '''Präprozessor'''. Dieser verändert den Quelltext, den die späteren Verarbeitungsphasen erhalten, in folgender Hinsicht:
* Einbeziehen zusätzlicher Dateien ([[Include-Files]])
* Ersetzen von (parametrisierbaren) [[Makro]]s
* Entfernen einzelner Abschnitte (= bedingte Kompilierung)

Im Grunde kann man sich den Präprozessor als eine Art Texteditor vorstellen, der die Anweisungen, was er zu tun hat, dem Text entnimmt, den er bearbeitet. In jedem Texteditor gibt es zb. die Funktion 'Suchen und Ersetzen'. Auch im Präprozessor gibt es sie, nur heißt sie dort #define. Alle Anweisungen an den Präprozessor beginnen grundsätzlich damit, daß das Zeichen '#' das erste Zeichen in einer Textzeile darstellt. Und umgekehrt: Ist das erste Zeichen in einer Textzeile ein '#', so handelt es sich um eine Präprozessor-Anweisung.

==#include==
Die #include weist den Präprozessor an, den Inhalt der angegebenen Datei anstelle der #include Anweisung einzusetzen. Weiter passiert nichts. Bei der Angabe des Dateinamens der einzusetzenden Datei gibt es 2 Formen
<syntaxhighlight lang="c">
#include "Datei1.xyz"
#include <Datei2.abc>
</syntaxhighlight>
Der Unterschied zwischen beiden Formen besteht rein im Aufsuchpfad, den der Präprozessor benutzt, um die Datei zu finden. Per Konvention wird die < >-Form benutzt, um systemweite Includes durchzuführen. Alle mit dem Compiler mitgelieferten Header Files sind zb. solche systemweite-Includes. Bei der Installation des Compilers wurde im System hinterlassen, auf welchem Pfad sie gefunden werden können. Durch Verwendung der < >-Form wird dem Präprozessor mitgeteilt, dass diese damals vereinbarten Pfadangaben zur Aufsuche dieser Datei benutzt werden soll.

==#define==
Mittels #define wird eine Textersetzung vereinbart.
<syntaxhighlight lang="c">
#define ABC xyz
</syntaxhighlight>
weist den Präprozessor an, im weiteren Quelltext alle Vorkommen von 'ABC' durch den Text 'xyz' zu ersetzen. Der Präprozessor macht dies überall, solange
* es sich an der zu ersetzenden Stelle um keinen String handelt. Mit obigem #define würde also in "Dies ist ABC" keine Textersetzung stattfinden.
* er den Ursprungstext als 'Wort' im Sinne eines C-Wortes handelt. Mit obigem #define würde also in cdABCef = 5; keine Textersetzung stattfinden.

Wichtig ist: Der Präprozessor führt eine reine Textersetzung durch! Ob sich durch diese Ersetzung eine Logikänderung im Programm ergibt, interessiert den Präprozessor nicht.

<syntaxhighlight lang="c">
#define NR 5

int Werte[NR];

...

for( i = 0; i < NR; i )
printf( "%d", Werte[i] );
</syntaxhighlight>

Bevor der eigentliche Compiler den Quelltext zu Gesicht bekommt, wird er zunächst vom Präprozessor bearbeitet. Dieser führt die Textersetzung durch, indem er alle Vorkommen von NR durch den Text 5 ersetzt. Erst dieses Ergebnis

<syntaxhighlight lang="c">
int Werte[5];

...

for( i = 0; i < 5; i )
printf( "%d", Werte[i] );
</syntaxhighlight>

wird dann dem eigentlichen Compiler zur Übersetzung vorgelegt. In diesem Beispiel hat man durch den Einsatz des Präprozessors erreicht, dass die Anzahl der Arrayelemente immer mit dem Maximalwert in der for-Schleife übereinstimmt. Ein Fehler, dass beispielweise die Arraygröße verändert wird, ohne das die for-Schleife angepasst würde, ist durch den Einsatz des Präprozessors wirkungsvoll verhindert worden.

Aber auch hier wieder: Der Präprozessors macht nur eine Textersetzung! Für den Präprozessors ist es völlig unerheblich, ob sich dadurch die Logik des Programms aus Sicht des Programmierers verändert
<syntaxhighlight lang="c">
#define PART 3+5

...

y = 8*PART;
</syntaxhighlight>
In diesem Beispiel mag es schon so sein, dass der Programmierer im Sinn hatte, den Ausdruck 3 mal 8 berechnen zu lassen, wobei sich die 8 durch eine Addition von 3 und 5 ergeben. Das interessiert aber den Präprozessor nicht. Der macht eine reine textuelle Ersetzung, indem er den Text 'PART' durch den Text '3+5' austauscht, wodurch dieses Ergebnis entsteht

<syntaxhighlight lang="c">
#define PART 3+5

...

y = 8*3+5;
</syntaxhighlight>
Dies ist aber etwas anderes, nämlich '(8*3)+5', also urspünglich beabsichtigt war, nämlich '8*(3+5)'.

Schlussfolgerung: Es ist bei komplexeren Makros nicht ungewöhnlich, dass sich in Makros relativ viele Klammern wiederfinden, deren Zweck gerade für einen Neuling nicht auf den ersten Blick zu durchschauen ist.
<syntaxhighlight lang="c">
#define PART (3+5)

...
x = PART;
y = 8*PART;
</syntaxhighlight>
Während die Klammern im Makro bei der Zuweisung an x keine Funktion erfüllen (aber auch nicht störend sind), sind sie bei der Zuweisung an y lebenswichtig um der ganzen Anweisung nach der Textersetzung die beabsichtigte Bedeutung zu geben.

==#if, #ifdef==

==mögliche Probleme beim Einsatz des Präprozessors==
Eine am C-Präprozessor häufig geäußerte Kritik ist, dass er (nahezu) ohne Berücksichtigung der eigentlichen Sprachsyntax arbeitet ("The C-Preprocessor doesn't know about C"). Die Tatsache, dass Makros beispielsweise auf der Basis von Textersatz arbeiten, kann zu Überaschungen führen. So wird in
<syntaxhighlight lang="c">
#define cub(a) a*a*a
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
in x nicht etwa der Wert 125 (5 hoch 3) stehen, sondern der Wert 13, da nach Ersetzen des Makros der folgende Quelltext kompiliert wird ...
<syntaxhighlight lang="c">
x = y+1*y+1*y+1;
</syntaxhighlight>
... und durch die arithmetischen Vorrangregeln, wird dieser Ausdruck so ausgewertet:

<syntaxhighlight lang="c">
x = y + (1*y) + (1*y) + 1;
</syntaxhighlight>

Deshalb sollte man jeden Parameter eines Makros bei jeder Verwendung klammern. Damit werden viele Probleme mit Makros gelöst und man erhält für obiges Beispiel folgende Form und damit auch eine korrekte Berechnung:
<syntaxhighlight lang="c">
#define cub(a) ((a)*(a)*(a))
...
int x, y;
y = 4;
x = cub(y+1);
...
</syntaxhighlight>
Ein weiteres Problem besteht jedoch, wenn ein Makro-Parameter im Ersatztext doppelt verwendet wird:
<syntaxhighlight lang="c">
#define max(a, b) ((a>b) ? (a) : (b))
...
int x, y;
...
x = max(y, 10); /* OK */
x = max(++y, 10); /* ?? */
</syntaxhighlight>
Im zweiten Fall wird die Variable ''y'' u.U. ''zweimal'' inkrementiert - was ohne Kenntnis der Makro-Definition keineswegs offensichtlich ist (''max'' könnte auch eine echte Funktion sein).

Die Tatsache, dass der C-Präprozessor die Syntax von C/C++ nicht wirklich berücksichtigt, ist allerdings auch nützlich. So lassen sich mit dem C-Präprozessor Datentypen parametrisieren, um systematische Programmteile zu vereinfachen:
<syntaxhighlight lang="c">
/* GSAWP:
generiert Funktionsdefinition zum Vertauschen des Inhalts von zwei Variablen
*/
#define GSWAP(n, T)s\
void n(T *xp, T *yp) { T tmp = *xp; *xp = *yp; *yp = tmp; }
...
GSWAP(iswap, int)
GSWAP(dswap, double)
GSWAP(swap_s, struct s)
...
int a, b;
double c, d;
struct s e, f;
...
iswap(&a, &b);
dswap(&c, &d);
swap_s(&e. &f);
</syntaxhighlight>

Viele typische Anwendungsfälle des Präprozessors lassen sich allerdings bereits mit Standard-C-Bordmitteln erfolgreich erschlagen:
* Statt ''#define'' besser mit ''const'' vereinbarte Variablen benutzen. Bei jedem besseren Compiler ergeben sich dank Optimierung keinerlei Nachteile.
* ''enum'' für Konstantenfelder benutzen. Dabei sollte man allerdings sauber casten, da ''enum''-Werte in der Regel als ''int'' interpretiert werden.
* Neuere Versionen des GCC unterstützen ''inline'', wodurch Makros für Einzeiler überflüssig werden.

In [[C++]] wurden ergänzend zum C-Präprozessor weitere Mechanismen eingeführt. So erlauben [[Templates (C++)|Templates]] generische Programmierung, womit viele der "Makro-Tricks" wie die obigen überflüssig werden.

[[Kategorie:C]]

Strukturen in C

2013-11-22T06:53:40Z

Kbuchegg: /* Motivation hinter Strukturen */

== Motivation hinter Strukturen ==

Ein struct ermöglicht es, einen logischen Zusammenhalt mehrerer Werte explizit auszudrücken und den Dingen einen Namen zu geben.

Beispielsweise besteht ein Datum nun mal aus Tag/Monat/Jahr
<syntaxhighlight lang="c">
struct date_
{
uint8_t Tag;
uint8_t Monat;
uint16_t Jahr;
};
</syntaxhighlight>
Der komplette Name einer Person besteht aus Vorname und Familienname
<syntaxhighlight lang="c">
struct name_
{
char Vorname[20];
char Familienname[30];
}
</syntaxhighlight>
Eine Ortsangabe besteht aus Postleitzahl, Ortsname, Strasse und Hausnummer
<syntaxhighlight lang="c">
struct ort_
{
char PLZ[6];
char Name[30];
char Strasse[30];
char Nummer[5];
};
</syntaxhighlight>

und eine komplette Personenbeschreibung besteht aus dem kompletten
Namen, einem Wohnort, seinem Geburtstag, seinem Hochzeitstag und der Anzahl der Kinder
<syntaxhighlight lang="c">
struct person
{
struct name_ Name;
struct date_ Geburtstag;
struct date_ Hochzeitstag;
struct ort_ Wohnort;
uint8_t NrKinder;
};
</syntaxhighlight>
Man sieht sehr schön, wie sich die Beschreibung einer Person mit den vorhergehenden Strukturen ganz automatisch strukturiert. Eine Person Franz

<syntaxhighlight lang="c">
struct person_ Franz;
</syntaxhighlight>
hat damit automatisch einen Monat in dem er geboren wurde. Er "erbt" dies, weil er einen Geburtstag hat und dieser als struct date_ klarerweise über ein Monat verfügt. Der Monat in dem Franz geboren wurde ist daher
<syntaxhighlight lang="c">
Franz.Geburtstag.Monat
</syntaxhighlight>
Liest man diesen C-Ausdruck von links nach rechts ist das Ganze weitgehend
selbsterklärend. Vom Allgemeineren zum immer Spezifischeren. 'Franz' ist die komplette Person. 'Franz.Geburtstag' ist der Geburtstag der Person Franz. 'Franz.Geburtstag.Monat' ist der Monat des Geburtstages der Person Franz.

Würde man zum struct ort_ noch das Land mit dazunehmen,
<syntaxhighlight lang="c">
struct ort_
{
char PLZ[6];
char Name[30];
char Strasse[30];
char Nummer[5];
char Land[30];
};
</syntaxhighlight>
dann 'erben' alle weiteren Strukturen oder Funktionen, die mit einem struct ort_
arbeiten ganz automatisch, dass ein struct ort_ jetzt auch noch das Land oder den Staat mit beinhaltet.

Strukturen sind Datentypen wie alle anderen eingebauten Datentypen auch (int, long, char, double, ...). Will man also beispielsweise die Belegschaft einer Firma speichern, die aus maximal 300 Personen besteht, dann kann man selbstverständlich ein derartiges Array von Personen erzeugen
<syntaxhighlight lang="c">
struct person_ Belegschaft[300];
int AnzahlPersonen;
</syntaxhighlight>
Damit hat man entsprechenden Speicher bereitgestellt um 300 Personen
speichern zu können. Mit allem drum und dran. Inklusive Wohnort, inklusive Geburtstag, inklusive eben allem was eine Person ausmacht. Jede einzelne Person der Belegschaft hat einen Geburtsmonat. Denn im Array sind ja lauter Personen gespeichert und jede ist vom Typ struct person_ und hat als solches einen Geburtstag.
Schreibt man sich daher eine Funktion, die einen beliebiges struct date_
ausgeben kann
<syntaxhighlight lang="c">
void printDate( struct date_ * Datum )
{
printf( "%d/%d/%04d", Datum->Tag, Datum->Monat, Datum->Jahr );
}
</syntaxhighlight>
dann kann man, weil ja ein Geburtstag einer Person so ein Datum ist, die Geburtstage der kompletten Belegschaft ausgeben
printf( "Geburtstage\n" );

for( i = 0; i < AnzahlPersonen; i++ ) {
printf( "%s %s: ", Belegschaft[i].Name, Belegschaft[i].Vorname );
printfDate( & Belegschaft[i].Geburtstag );
printf( "\n" );
}

Das ist aber nicht die einzige mögliche Verwendung so einer Funktion. Würde man für eine Person in der Belegschaft zb auch noch das Datum mitspeichern, an dem sie in die Firma gekommen ist.
<syntaxhighlight lang="c">
struct person
{
struct name_ Name;
struct date_ Geburtstag;
struct date_ Hochzeitstag;
struct date_ Firmeneintritt;
struct ort_ Wohnort;
};
</syntaxhighlight>
dann kann man selbstverständlich die Funktion printDate auch dazu benutzen, dieses Datum auszugeben. Denn auch ein 'Firmeneintritt' ist ja nur ein struct date_ und damit ist die Funktion dafür benutzbar
<syntaxhighlight lang="c">
printf( "Firmeneintritte\n" );

for( i = 0; i < 300; i++ ) {
printf( "%s %s: ", Belegschaft[i].Name, Belegschaft[i].Vorname );
printfDate( & Belegschaft[i].Firmeneintritt);
printf( "\n" );
}
</syntaxhighlight>
Ein anderes Beispiel wären Basisfunktionen, die zb mit einem struct date_ diverse Vergleiche oder Berechnungen anstellen, dann kann man dann zb. wiederrum Funktionen schreiben, die alle Mitarbeiter rausfiltern, die heuer 30 Jahre in der Firma sind, oder die gerade ihren 25. Geburtstag feiern etc, etc.

Aus einer 'logischen Gruppierung', in der man Dinge die zusammengehören auch in Form einer Datenstruktur zusammenfasst und strukturiert, folgt also wesentlich mehr als man jemals mit mehrspaltigen Arrays ausdrücken könnte. Man verpasst damit den beteiligten Daten eine Struktur die diesem logischen Zusammenhalt entspricht und versetzt sich damit in die Lage, die reale Welt besser und übersichtlicher und vor allen Dingen in 'der dem Programmierer gewohnten Sprache' in einem Programm abbilden zu können. Wieviel aussagekräftiger ist
<syntaxhighlight lang="c">
Belegschaft[i].Geburtstag.Monat
</syntaxhighlight>
als im Vergleich dazu
<syntaxhighlight lang="c">
Belegschaft[i][12]
</syntaxhighlight>
nur weil der Programmierer zufällig weißt, dass in der Spalte 12 eines 2-dimensionalen Arrays das Geburtsmonat gespeichert ist?

Zudem ermöglichst es Strukturen, dass man sich bei der Programmierung auf
Teilbereiche konzentrieren kann. Erstellt sich der Programmierer Funktionen, die
mit einem struct date_ arbeiten (egal ob Ausgeben, Vergleichen, Tage zwischen Daten berechnen, etc...), zu diesem Zeitpunkt konzentriert man sich nur und ausschliesslich auf das, was mit einem struct date_ möglich sein soll und wie diese Funktionalität zu implementieren ist.

Das dieses struct date_ dann in Form von Geburtstagen, Firmeneintritten,
Jubiläen etc. benutzt wird bzw. werden kann, ist beim Schreiben der Datumsfunktionen herzlich egal - und das soll es auch sein. Natürlich
wird die komplette Entwicklung dieser Funktionen durch das eigentliche Projekt getrieben werden, weil man ja weiß, was an Funktionalität in etwa gebraucht werden wird. Der springende Punkt ist aber, dass die entstehenden Funktionen erst mal damit nichts zu tun haben. Sie wären auch abseits dieses Projektes nützlich.

[[Kategorie:C]]

FAQ

2013-11-11T21:24:01Z

Kbuchegg: /* Header File wie geht das */

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

itoa() ist keine C-Standardfunktion (wohl aber ihre Umkehrung atoi() ). Auf manchen Compilern heisst diese Funktion dann folgerichtig _itoa(), wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Libary [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

itoa( i, Buffer, 10 ); - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array Buffer groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei printf() (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

Typ ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
c char
d int
f float, double
ld long
u unsigned int
lu unsigned long
p pointer
s string
x ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
X ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

+ Vorzeichen wird immer ausgegeben
- Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
0 anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Werftebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man itoa() nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j 

Das Grundprinzip ist einfach: 
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> 2
8392 / 10 -> 839

839 % 10 -> 9
839 / 10 -> 83

83 % 10 -> 3
83 / 10 -> 8

8 % 10 -> 8
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j 

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit eien Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

=Aktivieren der Floating Point Version von sprintf bei WinAVR bzw AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries'' In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous'' In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File - wie geht das =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen. Für dieses System soll eine Aufteilung erfolgen, so dass funtionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionIntA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SettingB 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur eine Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. CTC Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte TOP). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

FAQ

2013-11-11T21:23:20Z

Kbuchegg: /* Header File, wie geht das? */

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

itoa() ist keine C-Standardfunktion (wohl aber ihre Umkehrung atoi() ). Auf manchen Compilern heisst diese Funktion dann folgerichtig _itoa(), wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Libary [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

itoa( i, Buffer, 10 ); - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array Buffer groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei printf() (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

Typ ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
c char
d int
f float, double
ld long
u unsigned int
lu unsigned long
p pointer
s string
x ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
X ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

+ Vorzeichen wird immer ausgegeben
- Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
0 anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Werftebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man itoa() nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j 

Das Grundprinzip ist einfach: 
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> 2
8392 / 10 -> 839

839 % 10 -> 9
839 / 10 -> 83

83 % 10 -> 3
83 / 10 -> 8

8 % 10 -> 8
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j 

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit eien Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

=Aktivieren der Floating Point Version von sprintf bei WinAVR bzw AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries'' In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous'' In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File, wie geht das =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen. Für dieses System soll eine Aufteilung erfolgen, so dass funtionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionIntA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SettingB 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur eine Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. CTC Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte TOP). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

AVR Net-IO Bausatz von Pollin

2013-10-13T19:57:07Z

Kbuchegg: /* Funktionsumfang der Originalsoftware */

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058], oder als aufgebautes Fertigmodul, Best.Nr. 810 073.

Einige Features: Ethernet-Platine mit ATmega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

[[Datei:AVR-NET-IO ADD-ON.JPG|thumb|right|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang)und Add-On-Board (oben, mit aufgelötetem RFM12-433-Modul, beides nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen zur Stromversorgung wurden durch Buchsen ersetzt.]]

== Technische Daten ==

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (L×B×H): 108×76×22 mm.

== Hardware ==
=== AVR-NET-IO ===

Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe.

=== Erweiterungsplatine ===

Seit Januar 2010 gibt es auch eine Erweiterungsplatine

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot-Empfang
* [[RFM12]] Funkmodul (nicht im Lieferumfang enthalten)

Eine Aufstellung bekannter Fehler findet sich weiter unten [[#Bekannte Fehler|Bekannte Fehler - Erweiterungplatine]]

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805 - (Vorsicht: Der LM317T ist rückseitig spannungsführend. Den Kühlkörper also keinesfalls an beide Spannungsregler anschließen!)
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
** Laut Spezifikation sind auch mehr als 1µF erlaubt. Selbst Atmel verwendet beim STK500 10µF. Dies führt keinesfalls dazu, dass die RS232 nicht mehr funktioniert.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen (R3)
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen (R6,R7)
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig. - Kondensator bei selbstbau-ISP empfehlenswert.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
*** ??? Ist dies nicht kontraproduktiv? Bei mir wurde durch D2-Bestückung die Eingangsspannung von ca. 5,2 V am LM317T auf ca. 4,6 V gedrückt, so dass am ENC28J60 nur ca. 2,6 V ankamen (außerhalb der lt. Datenblatt "Operating voltage range of 3.14V to 3.45V"). Man müsste also ein geregeltes Netzteil mit ca. 5,5 V anschließen um 5 und 3,3 V zu erzielen. Dann lieber den Verpolungsschutz durch andere Maßnahmen sicherstellen.
** Beim Betrieb von USB beachten, dass USB-Spezifikation keinesfalls 5V garantiert, sondern Spannung bis runter 4.4V erlaubt und dann u.U. durch den LM317 nicht mehr genügend Spannung am ENC anliegt. Das äußert sich so, dass zwar der Atmega einwandfrei funktioniert, die Ethernet-Kommunikation aber nicht oder nur sehr sporadisch.
* Ersatz des ATmega32 durch einen ATmega644 oder ATmega1284p mit mehr FLASH-Speicher.
** Der ATmega644 und auch der ATMega1284p sind nicht mit der Pollin-Firmware kompatibel
* 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die serielle Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal ein Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===
[[image:fuse_bits_avr_studio.jpg|thumb|right|250px|Einstellungen der Fuse-Bits mittels AVR Studio 4]]
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.
{{Absatz}}

==== Funktionsfähige Konfiguration - AVR-Prog ====

[[Bild:Avrprog.png|thumb|right|250px]]
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m
und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0.0/24 Subnetz ====

Betreibt man den PC nicht im 192.168.0.0/24 Subnetz, muss er wie folgt umkonfiguriert werden, oder die IP Adresse des Boards wird entsprechend angepasst. ( Siehe Handbuch Seite 14ff. Das ist meist sinnvoller und auch einfacher. )

Den PC vom normalen Netzwerk abstecken[1]. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Anmerkung von bitman:
[1] Dies ist spätestens ab Windows XP nicht mehr notwendig, wenn das Netz 192.168.0.0/24 noch frei ist. Dann kann man einfach den Client ''zusätzlich'' in diesem Netzwerk zusätzlich einbinden über Einstellungen/Netzwerkverbindungen/Lanverbindung/Eigenschaften/TCP-IP/Eigenschaften/Erweitert/IP-Adresse hinzufügen. Es werden dann eben mehrere IP-Adressen an den NIC gebunden.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FB NETMASK 
3FC - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

Wenn sich nach dem scheinbar erfolgreichem Einspielen der Firmware, später nichts tut, so sollte die Firmware mit gesetztem "FailSafe" in der mitgelieferten NetServer-Software nochmals Eingespielt werden.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Funktionsumfang der Originalsoftware ==
Die Originalsoftware ist sehr einfach gestrickt. Im AVR Net-IO läuft ein Programm, welches am Port 50290 ein Textschnittstelle bereit stellt. Diese Schnittstelle kann sowohl über die RS232 als auch über Ethernet angesprochen werden kann. Mit diesem Programm ist es möglich, alle Eingänge sowie alle Ausgänge anzusprechen, als auch die Konfiguration der Netzwerkeinstellungen zu verändern. Die Karte versteht dann folgende Befehle:
* SETPORT
Einen digitalen Ausgang auf 0 oder 1 schalten
* GETPORT
Den Status eines digital Ausgangs/Eingangs abfragen
* GETSTATUS
Den Status aller digital Ausgänge abfragen
* GETADC
Den Messwert eines analogen Eingangs ermitteln
* SETIP
Die IP-Adresse des Boards ändern
* GETIP
Die eingestellte IP-Adresse abfragen
* SETMASK
Die Netzwerkmaske verändern
* GETMASK
Die eingestelle Netzwerkmaske abfragen
* SETGW
Das Netzwerk-Gateway verändern
* GETGW
Das eingestellte Netzwerk-Gateway abfragen
* INITLCD
Ein angeschlossenes LCD initialisieren
* WRITELCD
Einen Text am LCD ausgeben
* CLEARLCD
Ein angeschlossenes LCD löschen
* VERSION
Die Versionsnummer des Programms ausgeben

Dazu gibt es ein auf Java basierendes Programm, welches alternativ zu einem Terminalprogramm benutzt werden kann. Es zeigt den Status der Portpins an und diese lassen sich auch mit der Maus verändern. Die Messwerte der 4 analogen Eingänge werden ständig angezeigt, wobei es möglich ist, durch einstellbare Faktoren die internen Werte gleich in sinnvolle Einheiten umrechnen zu lassen. Diese Messwerte können auch in eine Datei geloggt werden.
Neben der Möglichkeit, alle Kommandos auch händisch einzugeben, wird das Java-Programm auch benötigt, um einen Firmware-Update der Net-IO Platine durchzuführen.
Alles in allem ist dieses Frontend aber mehr als Testumgebung anzusehen, um damit die Hardware in Betrieb zu nehmen. Für einen sinnvollen Dauereinsatz ist das Programm deutlich zu einfach und unflexibel gestrickt. Auch kann die grafische Aufbereitung der Anzeige- und Kontrollelemente nicht befriedigen.

== Bekannte Fehler ==
=== AVR-NET-IO ===

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]] 
Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt. Bei einem Bausatz gekauft 05/2013 ist dies ebenfalls noch der Fall.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

* Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10µF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1µF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Fertig gelötete Platine gekauft. µC war falsch im Sockel.

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert

* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel

* Bausatz August 10 gekauft: komplett und sofort funktioniert

* Bausatz Juli 10 gekauft: 2 Quarze mit 16 MHz geliefert, statt 1x 16MHz und 1x25MHz.

* Bausatz September 10 gekauft: hat sofort funktioniert. 1x 3,3k und 1x 10k Widerstand zuviel. Statt 100nF Kondensatoren wurden 1µF geliefert -> Platzprobleme auf der Platine durch grössere Bauform. LED grün.

* Bausatz Oktober 6 gekauft: alles funktioniert. LED grün statt rot.

* Fertigmodul Oktober 10 gekauft: Auf Anhieb alles funktioniert!

* Bausatz Oktober 10 gekauft: komplett und sofort funktioniert

* Bausatz November 10 gekauft: komplett und sofort funktioniert (sogar mit der neusten Pollin Firmware 1.03 schon drauf) LED grün statt rot.

* Bausatz November 10 gekauft. Nach Bezug neuer Feinst-Lötspitzen konnte ich ihn dann auch zusammenlöten. Es hat sofort alles funktioniert, obwohl ich nur 12V bzw. 9V Gleichspannung zur Verfügung hatte, und nicht sicher war, wieviel die Komponenten wirklich benötigen. Der Regler wird auch bei 9V Gleichspannungsversorgung noch sehr warm. Da muss auf jeden Fall ein Kühlkörper dran! Ich habe auch eine grüne LED bekommen, ist mir aber wurscht :-)

* Bausatz Dezember 10 gekauft: komplett und funktionierte sofort. Firmware 1.03, grüne LED (Ein Quarz und ein IC-Sockel zu viel)

* Bausatz Januar 2011 gekauft: nur genau die richtige Anzahl Teile dabei, Firmware 1.03, grüne LED, ging auf Anhieb

* 2x Bausatz Januar 2011 gekauft: beide grüne LED, und 1x doppelter Satz Jumper/Stiftleiste, 22PF und Anschlussklemmen. Rest vollständig und beide haben sofort nach zusammenbau funktioniert.

* Februar 2011: AVR-NET-IO: die Diode D5 fehlt, 10 µF gegen 1 µF für MAX232 getauscht, Flash im ATmega32 war programmiert, passende IP-Adr über serielle Schnittstelle eingestellt; ADD-ON: für R1 war 22Ω statt 0,2Ω beigelegt, durch richtigen ersetzt, Beschreibung der LED Bestückung mangelhaft / oe1smc

* Februar 2011: AVR-NET-IO: 1 Diode zuviel, 2 Spulen fehlen, LED grün. Die fehlenden Spulen wurden durch welche aus der Bastelkiste ersetzt - funktioniert. Der 7805 bekam einen kleinen Kühlkörper spendiert.

* Februar 2011: AVR-NET-IO: 2x 10k Widerstände fehlen. Dafür eine Diode zu viel.

* Ende Februar 2011: Zwei Bausaetze an jeweils zwei Adressen, alles in Ordnung.

* Ende März 2011: 2x 25 Mhz Quarz statt 1x16 u. 1x25 Mhz. LED fehlt. Bausatz funktioniert nach Tausch des Quarz den mir mein Freund oe9rsv aus seinem Fundus spendiert hat. Danke auch für die Hilfe beim Fehler suchen.

* Mitte 2010 gekauft: 1x 100nF fehlt

* Mitte Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, Pollin wollte, dass ich das ganze Paket zurückschicke für einen Austausch. Ein 51Ω zu viel. 16Mhz im Handel und 25Mhz vom alten Mobo ausgelötet. Läuft wunderbar.

* Anfang Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, nach kurzer Mail an Pollin (leider ohne Antwort) wurden diese nach ca. 1 Woche in einem Brief nachgeliefert.

* August 2011: alles 1a...

* August 2011: Platine fehlte -> in Nachlieferung

* 30 August 2011: alles 1a...

* 06 Sep. 2011: alles 1a...

* August 2011: 6 Stück bestellt, bei einem haben die 100nF Kondensatoren gefehlt, bei einem zwei LM317 statt 7805 und LM317. Angerufen, 3 Tage später Nachlieferung erhalten.

* Nov. 2011: '''Net_IO''' vollständig. Einspielen der Firmware 1.03 war erforderlich. Bei '''Add-On''' immer noch falscher Q1 BC548 (NPN) in Stückliste und Lieferung. BC327-40 oder BC328-40 (PNP) nachgefordert. R11 und R24 mitgeliefert, entsprechend Beschreibung V1.1 von Pollin's Download. Beiliegende Beschreibung war älter, ohne diese Widerstände.

* Ende Nov.2011, alle Teile dabei, Firmware war drauf, sofort funktioniert.

* Anfang Dez.2011, komplett bestückte Platine gekauft. Auf 7805 Kühlkörper gebaut, da er nach 1 Minute schon ausgestiegen ist (LED hat das Pumpen angefangen). Firmware 1.03 musste noch aufgespielt werden danach funktioniert alles einwandfrei. In Betrieb mit 10V DC

* Ende Dez.2011 2xNET-IO und 2xADD bestellt, 4 verschieden volle Kisten bekommen... WSL16 ist mit Verriegelung, geht nicht aufs Board, Jumper fehlen, Spannungsregler doppelt, Poti Löcher zu klein, lsb3 fehlt, SD-Slot hab ich jetzt 3, 100nF hab ich jetzt 4 übrig ... also immer noch lustig. HW-Stand immer noch 1.0 ( gab es überhaupt eine 1.1?)

* Mitte Jan. 2012, 10pol. beide Wannenstecker nicht dabei, Firmware war drauf, sofort funktioniert. 1 LED zuviel. Unproblematische Nachlieferung bei Reklamation (wegen der beiden Wannenstecker kam ein PAKET!).

* Ende Feb. 2012, Um die PHP-Scripte über öffentlichen Webserver zu betreiben muss mit SETGW die Gateway-Adresse des lokalen Routers eingetragen werden. Bei der NAT im Router sollte z.B. Port 8080 auf den internen Port 50290 umgeleitet werden, da manche Provider diesen Port für die Socket-Kommunikation nicht zulassen.

* Juli 2012, Bausatz vollständig, Nach Aufbau sofort den 7805 mit einem kleinen Kühlkörper versehen, da er sonst thermisch überlastet wird! hat weder auf LAN noch RS232 reagiert, musste erst Update einspielen (Download Pollin), danach funktionierte alles einwandfrei!

* Januar 2013, Bausatz vollständig, 7805 mit Kühlkörper versehen, nach Aufbau ohne Probleme funktioniert

* Februar 2013, Bausatz komplett, Aufbau ohne Probleme, 7805 nur leicht warm, LAN funktioniert, RS232 noch ohne Funktion.

* Oktober 2013, Bausatz komplett laut Stückliste, problemloser Aufbau, 7805 leicht warm am 10V DC. RS232 und LAN funktionierten auf Anhieb.

=== Erweiterungsplatine ===

Die nachfolgend genannten Änderungen sind in der Bauanleitung V1.1 mit Stand 07.12.2011 (Wichtig! Es gibt mehr als eine V1.1 ...) bereits berücksichtigt, R3 wird allerdings mit 3,6kΩ angegeben.

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5kΩ ersetzen mit 2kΩ
*R3 1,8K ersetzen mit 3,3kΩ
*R19 470kΩ ersetzen zu 470Ω
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache PNP! und mehr als 100mA)

'''ACHTUNG''' beim Anschluß eines LC-Displays an J5 (über I2C, PCF 8574): Vcc/5V liegt an Pin 1, GND an Pin 2 von J5. Es gibt etliche Displays mit abweichender Belegung Pin 1 GND und Pin 2 Vcc!

Auch beim Add-On gibt es fehlende oder falsche Bauteile im Bausatz und Fehler im Schaltplan und auf der Platine:

*Stand Feb. 2011: R2 wird mit 2,2kΩ und R3 wird mit 3,6kΩ ausgeliefert. Somit werden die 3,3 V richtig erzeugt. R19 hat 470Ω. Der ISP-Anschluß ist nicht vollständig durchgeschleift, es besteht keine Verbindung der RESET-Leitung zwischen ISP und ISP1 (Abhilfe: Drahtbrücke einlöten, [http://www.mikrocontroller.net/topic/161354#1600385 Quelle]).

*Stand Nov. 2011: bei mir ist die RESET-Leitung korrekt zw. ISP und ISP1 verbunden. Es gibt jetzt auch einen R24 (470Ohm) und R11 (1KOhm), der in der bei mir mitgelieferten Bauanleitung fehlt, in der zum Download (V1.1) angebotenen aber drin steht. Es wird immer noch der falsche Q1 BC548C (NPN) mitgeliefert. Das Schaltsymbol für einen PNP ist richtig im Schaltplan gezeichnet.

*Stand Dez. 2011: R24 (470Ω) kann mit 0Ω ersetzt und R11 (1kΩ) völlig weggelassen werden. Diese Widerstände bilden einen (eigentlich überflüssigen) Spannungsteiler in der MISO Leitung. Der Spannungsteiler hat allerdings auch eine Schutzfunktion, falls weitere Slaves am SPI-Bus hängen, die 5V-Pegel nutzen, z. B. ISP-Programmierer. (siehe [http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=1167&postid=9203 1284p: Board, ich oder beide verwirrt?])

*Sept'12: Bausatz mit Stecker anstelle einer Buchse ausgeliefert, 5mm anstelle von 3mm LED's dafür aber 3 Poti zuviel.

*Sept'12: Ebenfalls Bausatz mit Sub-D-Stecker statt Buchse ausgeliefert, 5mm anstelle von 3mm LED's und 3 Potis zuviel.

*Stand März 2013: Die Belegung der 25 pol. Sub-D-Buchse im Schaltplan der Anleitung V1.1 (und früher) ist falsch dargestellt. SCL und SDA des I2C-Busses liegen wie beim AVR-NET-IO Board auf Pin 2 bzw. 3 und nicht auf Pin 11 bzw. 12 der Buchse. Ein 1:1 verdrahtetes Kabel funktioniert.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

Links gehen nicht:
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== E2000-NET-IO-Multi-Control ===
Mti dem E2000-NET-IO-Multi-Control ist es möglich, die vom dem E2000-NET-IO-Designer erstellten Projekte zu öffnen und die AVR-NET-IO's zu steuern.

Die Anwendung liegt dem [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#E2000-NET-IO-Designer_.28Windows.5BXP.2F7.5D_.2F_Android.29 E2000-NET-IO-Designer] bei.

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

=== JAVA Lib ===
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.
http://son.ffdf-clan.de/?path=forumsthread&threadid=611

=== PHP ===
PHP Klasse zur Ansteuerung mit der Originalfirmware. (Opensource Lizenz)
http://blog.coldtobi.de/1_coldtobis_blog/archive/298_pollin_net-io_php_library.html

PHP Funktionen zum Ansteuern der Originalfirmware. (Free for All Lizenz)
http://defcon-cc.dyndns.org/wiki/index.php/Pollin_AVR-NetIO_PHP_Wrapper

== Clients für Smartphones ==

=== AVR NET IO Control (Windows Phone 7.5,7.8,8.0) ===

Freie App zur steuerung des AVR NET IO.

'''App im Market: [http://www.windowsphone.com/de-de/store/app/avr-net-io-controll/030d107f-9a27-4a62-ac8f-cb74e79c0500 AVR NET IO Control]'''
=== App NetIO (Windows Mobile 6.5) ===
Frei verfügbare App für Windows Mobile zur Ansteuerung mit der Orginalsoftware. Das HTC HD2 wird damit zur Fernsteuerung für das AVR Net-IO Board.
http://www.heesch.net/netio.aspx

=== NET-IO Control (Android) ===
Eine Application für das Android Betriebssystem zur Steuerung des AVR Net-IO Boards. Es ist möglich, alle Ausgänge zu steuern und alle Eingänge anzuzeigen. Die Analogen Eingänge können mit einem Berechnungsfaktor versehen werden. ''Geplant ist noch ein Offsetwert.'' Außerdem kann jedem analogen Wert eine Einheit zugeordnet werden. Die Ausgänge können in der neusten Version in einen Tastermodus gesetzt werden.

[[Datei:NET-IO-Control.png|200px]] [[Datei:NET-IO-Control2.png|200px]] [[Datei:NET-IO-Control3.png|200px]]

'''Trial-Version: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControlTRAIL Google-Play]'''

(In dieser Probe Version können nur 1 Output und 2 Inputs gesteuert werden)

'''Vollversion: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControl Google-Play]'''

(Kostet im Google-Play 3,00 €)

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== E2000-NET-IO-Designer (Windows[XP/7] / Android) ===
[[Datei:E2000-NET-IO-Designer.png|400px|right]]
Mit dem E2000-NET-IO-Designer ist es möglich, eine grafische Oberfläche für die NET-IOs von Pollin zu erstellen. Dafür werden Knöpfe, Texte und Anzeigebilder zur Verfügung gestellt. Jedes dieser Element kann "Aufgaben" übernehmen um die NET-IOs zu steuern oder einen Status des NET-IO anzuzeigen. Weitere Icons können von dem Benutzer selbst in den entsprechenden Ordner gelegt werden und in die Oberfläche eingebunden werden. Es können mehrere Seiten designt werden die durch einen selbst positionierten Knopf erreichbar sind. Die Android Application arbeitet somit im Fullscreen-Modus. Des weiteren ist es möglich, mehrere NET-IO's in einem Projekt zu benutzen. Nach dem erstellen der grafischen Oberfläche mit dem E2000-NET-IO-Designer, kann mit der Android APP das Projekt einfach gedownloaded werden. Dafür baut die APP eine Verbindung zum E2000-NET-IO-Designer auf und läd alle benötigten Dateien herunter (Achtung: Firewall-Einstellungen beachten). Die designten Oberflächen können außerdem noch mit der E2000-NET-IO-Multi-Control.exe auf dem Computer ausgeführt werden. Dadurch ist es Möglich, seine NET-IOs vom PC aus zu steuern über eine selbst designte Oberfläche.

Zum Ausführen des E2000-NET-IO-Designer muss .NET Framework 4.0 installiert sein und es muss eine Internetverbindung exisitieren.

'''Features:'''<ul>
<li>Grafische Oberfläche am PC erstellen</li>
<li>Verwendung von eigenen Button- und Hintergrundbildern</li>
<li>Designbare Anzeige von Digital- und Analogwerten</li>
<li>Steuern von mehreren AVR-NET-IO Boards</li>
<li>Unterstützung der E2000-NET-IO Firmware (mehere Boards gleichzeitig)</li>
<li>Designte Steuerungen können auf dem PC oder dem Handy ausgeführt werden (Android)</li>
<li>Schnelle Verbindung</li>
<li>Einfache übertragung auf das Handy durch Projekt Download</li>
</ul>

[http://www.elektronik2000.de/downloads.php?id=44 Download E2000-NET-IO-Designer]

[http://www.elektronik2000.de/hilfe/E2000Netdesigneruebersicht.html Online Hilfe]

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== NetIO ( iPhone & Android ) ===
<div style="float: left; margin-right: 20px">[[Datei:Netio_logo.png|70px]]</div>

Schöne universelle Fernbedienung für das Board (iOS / Android). Konfigurierbar über einen Browserbasierten Editor. 
Unterstützt TCP socket Verbindungen, kann http request absetzen und kann auch Webseiten einbinden (z.B. IP-Kameras). Kann mehrere
Boards gleichzeitig steuern! Einfach super schnell ins Projekt eingebaut... Es gibt Buttons (die auch als Taster konfiguriert werden können), Slider, Switches und einfache Labels. Dinge können geschaltet oder Daten ausgelesen und mit regex dargstellt werden.

<div style='float: right'>
[[Datei:Netio_TV.png|190px]]
[[Datei:Netio_iphone5.png|190px]]
[[Datei:NetIO_appflow.jpg|190px]]
</div>

 
AppStore Link: http://itunes.apple.com/app/netio/id464924297?mt=8 
Google Play Link: https://play.google.com/store/apps/details?id=com.luvago.netio 
Die gleiche Konfiguration kann auch mit einem [https://github.com/davideickhoff/NetIO-OSX-Dashboard-Widget OSX Widget] benutzt werden. 
Webseite: http://netio.davideickhoff.de

Hinweis: Man findet es unter "NetIO" im Store, im Icon selbst und in iTunes wird es als "Controller" angezeigt. 
Die eigene Konfiguration kann man mit dem [http://netio.davideickhoff.de/editor Online Editor] vorher am PC erstellen.
Eine fertige [http://netio.davideickhoff.de/editor/?config=pollin AVR-NET-IO Konfiguration] gibt es als funktionierendes Beispiel schon als Preset.

 
<div style='clear: both'></div>

=== AVR Net IO (iPhone) ===
[[Datei:AVRNetIO-Screenshot1.png|160px|rechts]]
Update 15.12.2011: Die Neue Version 1.3 ist seit gestern im AppStore. Fehlerkorrekturen und ein robusteres Handling machen die App nun zur universellen AVR-Net-IO-Steuerung.

Mit der [http://itunes.apple.com/de/app/avr-net-io/id460991760?mt=8 iPhone App AVR-Net-IO] kann das Board ferngesteuert werden. Die Fernsteuerung umfasst in der Version 1.1 folgende Funktionen: <ul>
<li>ADC-Werte zyklisch auslesen und darstellen</li>
<li>Digital-Inputs zyklisch darstellen</li>
<li>Digital-Outputs können über Buttons geschaltet werden. Die Werte der Digital-Outputs werden zuerst ausgelesen und zeigen den zuletzt gesetzten Wert an.</li>
<li>Terminal-Modus: Hier können beliebige AVR-Net-IO-Befehle eingegeben werden. Das Ergebnis wird 1:1 angezeigt, wie es vom Board kommt. Hilfreich für Tests bei Eigenentwicklungen und Konfigurationen.</li>
</ul>
 
Mehr Infos gibt's dazu direkt von den Entwicklern auf [http://www.facebook.com/pages/AVR-Net-IO/187799687958255?ref=nf AVR-net-IO Facebook-Page] oder direkt auf deren Homepage [http://www.ondics.de/apps/1001/ Homepage].
 
Hinweis: MIt der aktuellen Version 1.1 gibt es noch bei manchen Boards Probleme beim auslesen und anzeigen der ADC- und Digital-Werte. Das Terminal funzt problemlos. Die Entwickler kümmern sich gerade drum und haben einen baldigen Update versprochen.
 

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== E2000 - Logik ===

[[Datei:E2000-Logik-Bedienoberflaeche.jpg|500px|rechts]]

Anwenderfreundliche Logik-Software von Elektronik2000.de zur Steuerung des AVR-NET-IO. Der ATMEGA32 wird durch einen ATMEGA644 ersetzt und mit der E2000-Firmware beschrieben. Nun ist es möglich in der E2000-Logik Software eine Logikschaltung zu erstellen und diese auf das NET-IO-Board zu übertragen. Dort wird diese Schaltung simuliert. Dies funktioniert komplett ohne einen Computer.

Durch ein Erweiterungsboard von Elektronik2000.de ist es auch möglich, das Board ohne Internet laufen zu lassen eine RTC (RealTimeClock) übernimmt dabei die Uhrzeitgesteuerten Funktionen. Auf dieser Erweiterung ist auch ein EEPROM integriert, um Firmware-Updates über Netzwerk einzuspielen (in Zukunft). Diese Erweiterung bietet außerdem die Anbindung an das E2000-Bus-System, durch das es möglich ist das AVR-NET-IO-Board durch weitere Ein- und Ausgänge zu erweitern.

Das Designen von Schaltaufgaben wird in diesem Programm grafisch dargestellt, durch das ein einfaches Anpassen seiner Logikschaltungen möglich ist.

Eine Steuerung des E2000-NET-IO ist möglich durch den Intregrieten Webserver, die PC-Software (E2000-NET-IO Control) oder der Androidsoftware. All diese Können gleichzeitig auf das E2000-NET-IO zugreifen und Funktionen ausführen.

Weitere Informationen gibt es auf der Entwicklerseite: [http://www.elektronik2000.de Elektronik2000.de]

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere in der Datei ENC28J60.H:
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 
Um diesen Code mit einem Atmega1284P verwenden zu können, muss in der main.c in Zeile 38, "TIMSK" durch "TIMSK1" ersetzt werden.
Die Fusebits für den Atmega1284p ohne Bootloader sind:
lfuse=0xFF, hfuse=0xD9, efuse=0xFF

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== Avr ArtNET-Node ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt, dass viel Arbeit und Liebe in diesem Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-Systems, welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== OpenMLP ===
Auf openMCP basierender Port nach [http://avr.myluna.de LunaAVR] (GPL). Umfangreiche Funktionalität und direkte Anpassung an die Sprache. Abgespeckte Version auch auf Atmega32 lauffähig. Die Original-Dokumentation kann zum Großteil hergenommen werden. Einige Zusatzfeatures. Leichte Konfiguration und guter Einstieg für Anfänger und zum Verständnis der Serverfunktionalität.

[http://avr.myluna.de/doku.php?id=de:openmlp Artikelseite]
[http://forum.myluna.de/viewtopic.php?f=8&t=13 Forum]

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

=== AVR-Netino ===
[http://code.google.com/p/avr-netino/ Projekt und Software]

Arduino fürs Net-IO

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://avr.myluna.de/doku.php?id=de:openmlp LunaAVR openMLP ]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

AVR Net-IO Bausatz von Pollin

2013-10-13T19:55:56Z

Kbuchegg:

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058], oder als aufgebautes Fertigmodul, Best.Nr. 810 073.

Einige Features: Ethernet-Platine mit ATmega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

[[Datei:AVR-NET-IO ADD-ON.JPG|thumb|right|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang)und Add-On-Board (oben, mit aufgelötetem RFM12-433-Modul, beides nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen zur Stromversorgung wurden durch Buchsen ersetzt.]]

== Technische Daten ==

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (L×B×H): 108×76×22 mm.

== Hardware ==
=== AVR-NET-IO ===

Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe.

=== Erweiterungsplatine ===

Seit Januar 2010 gibt es auch eine Erweiterungsplatine

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot-Empfang
* [[RFM12]] Funkmodul (nicht im Lieferumfang enthalten)

Eine Aufstellung bekannter Fehler findet sich weiter unten [[#Bekannte Fehler|Bekannte Fehler - Erweiterungplatine]]

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805 - (Vorsicht: Der LM317T ist rückseitig spannungsführend. Den Kühlkörper also keinesfalls an beide Spannungsregler anschließen!)
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
** Laut Spezifikation sind auch mehr als 1µF erlaubt. Selbst Atmel verwendet beim STK500 10µF. Dies führt keinesfalls dazu, dass die RS232 nicht mehr funktioniert.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen (R3)
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen (R6,R7)
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig. - Kondensator bei selbstbau-ISP empfehlenswert.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
*** ??? Ist dies nicht kontraproduktiv? Bei mir wurde durch D2-Bestückung die Eingangsspannung von ca. 5,2 V am LM317T auf ca. 4,6 V gedrückt, so dass am ENC28J60 nur ca. 2,6 V ankamen (außerhalb der lt. Datenblatt "Operating voltage range of 3.14V to 3.45V"). Man müsste also ein geregeltes Netzteil mit ca. 5,5 V anschließen um 5 und 3,3 V zu erzielen. Dann lieber den Verpolungsschutz durch andere Maßnahmen sicherstellen.
** Beim Betrieb von USB beachten, dass USB-Spezifikation keinesfalls 5V garantiert, sondern Spannung bis runter 4.4V erlaubt und dann u.U. durch den LM317 nicht mehr genügend Spannung am ENC anliegt. Das äußert sich so, dass zwar der Atmega einwandfrei funktioniert, die Ethernet-Kommunikation aber nicht oder nur sehr sporadisch.
* Ersatz des ATmega32 durch einen ATmega644 oder ATmega1284p mit mehr FLASH-Speicher.
** Der ATmega644 und auch der ATMega1284p sind nicht mit der Pollin-Firmware kompatibel
* 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die serielle Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal ein Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===
[[image:fuse_bits_avr_studio.jpg|thumb|right|250px|Einstellungen der Fuse-Bits mittels AVR Studio 4]]
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.
{{Absatz}}

==== Funktionsfähige Konfiguration - AVR-Prog ====

[[Bild:Avrprog.png|thumb|right|250px]]
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m
und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0.0/24 Subnetz ====

Betreibt man den PC nicht im 192.168.0.0/24 Subnetz, muss er wie folgt umkonfiguriert werden, oder die IP Adresse des Boards wird entsprechend angepasst. ( Siehe Handbuch Seite 14ff. Das ist meist sinnvoller und auch einfacher. )

Den PC vom normalen Netzwerk abstecken[1]. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Anmerkung von bitman:
[1] Dies ist spätestens ab Windows XP nicht mehr notwendig, wenn das Netz 192.168.0.0/24 noch frei ist. Dann kann man einfach den Client ''zusätzlich'' in diesem Netzwerk zusätzlich einbinden über Einstellungen/Netzwerkverbindungen/Lanverbindung/Eigenschaften/TCP-IP/Eigenschaften/Erweitert/IP-Adresse hinzufügen. Es werden dann eben mehrere IP-Adressen an den NIC gebunden.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FB NETMASK 
3FC - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

Wenn sich nach dem scheinbar erfolgreichem Einspielen der Firmware, später nichts tut, so sollte die Firmware mit gesetztem "FailSafe" in der mitgelieferten NetServer-Software nochmals Eingespielt werden.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Funktionsumfang der Originalsoftware ==
Die Originalsoftware ist sehr einfach gestrickt. Im AVR Net-IO läuft ein Programm, welches am Port 50290 ein Textschnittstelle bereit stellt. Diese Schnittstelle kann sowohl über die RS232 als auch über Ethernet angesprochen werden kann. Mit diesem Programm ist es möglich, alle Eingänge sowie alle Ausgänge anzusprechen, als auch die Konfiguration der Netzwerkeinstellungen zu verändern. Die Karte versteht dann folgende Befehle:
* SETPORT
Einen digitalen Ausgang auf 0 oder 1 schalten
* GETPORT
Den Status eines digital Ausgangs/Eingangs abfragen
* GETSTATUS
Den Status aller digital Ausgänge abfragen
* GETADC
Den Messwert eines analogen Eingangs ermitteln
* SETIP
Die IP-Adresse des Boards ändern
* GETIP
Die eingestellte IP-Adresse abfragen
* SETMASK
Die Netzwerkmaske verändern
* GETMASK
Die eingestelle Netzwerkmaske abfragen
* SETGW
Das Netzwerk-Gateway verändern
* GETGW
Das eingestellte Netzwerk-Gateway abfragen
* INITLCD
Ein angeschlossenes LCD initialisieren
* WRITELCD
Einen Text am LCD ausgeben
* CLEARLCD
Ein angeschlossenes LCD löschen
* VERSION
Die Versionsnummer des Programms ausgeben

Dazu gibt es ein auf Java basierendes Programm, welches alternativ zu einem Terminalprogramm benutzt werden kann. Es zeigt den Status der Portpins an und diese lassen sich auch mit der Maus verändern. Die Messwerte der 4 analogen Eingänge werden ständig angezeigt, wobei es möglich ist, durch einstellbare Faktoren die internen Werte gleich in sinnvolle Einheiten umrechnen zu lassen. Diese Messwerte können auch in eine Datei geloggt werden.
Neben der Möglichkeit, alle Kommandos auch händisch einzugeben, wird das Windows Programm auch benötigt, um einen Firmware-Update der Net-IO Platine durchzuführen.
Alles in allem ist dieses Windows-Frontend aber mehr als Testumgebung anzusehen, um damit die Hardware in Betrieb zu nehmen. Für einen sinnvollen Dauereinsatz ist das Programm deutlich zu einfach und unflexibel gestrickt. Auch kann die grafische Aufbereitung der Anzeige- und Kontrollelemente nicht befriedigen.

== Bekannte Fehler ==
=== AVR-NET-IO ===

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]] 
Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt. Bei einem Bausatz gekauft 05/2013 ist dies ebenfalls noch der Fall.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

* Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10µF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1µF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Fertig gelötete Platine gekauft. µC war falsch im Sockel.

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert

* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel

* Bausatz August 10 gekauft: komplett und sofort funktioniert

* Bausatz Juli 10 gekauft: 2 Quarze mit 16 MHz geliefert, statt 1x 16MHz und 1x25MHz.

* Bausatz September 10 gekauft: hat sofort funktioniert. 1x 3,3k und 1x 10k Widerstand zuviel. Statt 100nF Kondensatoren wurden 1µF geliefert -> Platzprobleme auf der Platine durch grössere Bauform. LED grün.

* Bausatz Oktober 6 gekauft: alles funktioniert. LED grün statt rot.

* Fertigmodul Oktober 10 gekauft: Auf Anhieb alles funktioniert!

* Bausatz Oktober 10 gekauft: komplett und sofort funktioniert

* Bausatz November 10 gekauft: komplett und sofort funktioniert (sogar mit der neusten Pollin Firmware 1.03 schon drauf) LED grün statt rot.

* Bausatz November 10 gekauft. Nach Bezug neuer Feinst-Lötspitzen konnte ich ihn dann auch zusammenlöten. Es hat sofort alles funktioniert, obwohl ich nur 12V bzw. 9V Gleichspannung zur Verfügung hatte, und nicht sicher war, wieviel die Komponenten wirklich benötigen. Der Regler wird auch bei 9V Gleichspannungsversorgung noch sehr warm. Da muss auf jeden Fall ein Kühlkörper dran! Ich habe auch eine grüne LED bekommen, ist mir aber wurscht :-)

* Bausatz Dezember 10 gekauft: komplett und funktionierte sofort. Firmware 1.03, grüne LED (Ein Quarz und ein IC-Sockel zu viel)

* Bausatz Januar 2011 gekauft: nur genau die richtige Anzahl Teile dabei, Firmware 1.03, grüne LED, ging auf Anhieb

* 2x Bausatz Januar 2011 gekauft: beide grüne LED, und 1x doppelter Satz Jumper/Stiftleiste, 22PF und Anschlussklemmen. Rest vollständig und beide haben sofort nach zusammenbau funktioniert.

* Februar 2011: AVR-NET-IO: die Diode D5 fehlt, 10 µF gegen 1 µF für MAX232 getauscht, Flash im ATmega32 war programmiert, passende IP-Adr über serielle Schnittstelle eingestellt; ADD-ON: für R1 war 22Ω statt 0,2Ω beigelegt, durch richtigen ersetzt, Beschreibung der LED Bestückung mangelhaft / oe1smc

* Februar 2011: AVR-NET-IO: 1 Diode zuviel, 2 Spulen fehlen, LED grün. Die fehlenden Spulen wurden durch welche aus der Bastelkiste ersetzt - funktioniert. Der 7805 bekam einen kleinen Kühlkörper spendiert.

* Februar 2011: AVR-NET-IO: 2x 10k Widerstände fehlen. Dafür eine Diode zu viel.

* Ende Februar 2011: Zwei Bausaetze an jeweils zwei Adressen, alles in Ordnung.

* Ende März 2011: 2x 25 Mhz Quarz statt 1x16 u. 1x25 Mhz. LED fehlt. Bausatz funktioniert nach Tausch des Quarz den mir mein Freund oe9rsv aus seinem Fundus spendiert hat. Danke auch für die Hilfe beim Fehler suchen.

* Mitte 2010 gekauft: 1x 100nF fehlt

* Mitte Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, Pollin wollte, dass ich das ganze Paket zurückschicke für einen Austausch. Ein 51Ω zu viel. 16Mhz im Handel und 25Mhz vom alten Mobo ausgelötet. Läuft wunderbar.

* Anfang Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, nach kurzer Mail an Pollin (leider ohne Antwort) wurden diese nach ca. 1 Woche in einem Brief nachgeliefert.

* August 2011: alles 1a...

* August 2011: Platine fehlte -> in Nachlieferung

* 30 August 2011: alles 1a...

* 06 Sep. 2011: alles 1a...

* August 2011: 6 Stück bestellt, bei einem haben die 100nF Kondensatoren gefehlt, bei einem zwei LM317 statt 7805 und LM317. Angerufen, 3 Tage später Nachlieferung erhalten.

* Nov. 2011: '''Net_IO''' vollständig. Einspielen der Firmware 1.03 war erforderlich. Bei '''Add-On''' immer noch falscher Q1 BC548 (NPN) in Stückliste und Lieferung. BC327-40 oder BC328-40 (PNP) nachgefordert. R11 und R24 mitgeliefert, entsprechend Beschreibung V1.1 von Pollin's Download. Beiliegende Beschreibung war älter, ohne diese Widerstände.

* Ende Nov.2011, alle Teile dabei, Firmware war drauf, sofort funktioniert.

* Anfang Dez.2011, komplett bestückte Platine gekauft. Auf 7805 Kühlkörper gebaut, da er nach 1 Minute schon ausgestiegen ist (LED hat das Pumpen angefangen). Firmware 1.03 musste noch aufgespielt werden danach funktioniert alles einwandfrei. In Betrieb mit 10V DC

* Ende Dez.2011 2xNET-IO und 2xADD bestellt, 4 verschieden volle Kisten bekommen... WSL16 ist mit Verriegelung, geht nicht aufs Board, Jumper fehlen, Spannungsregler doppelt, Poti Löcher zu klein, lsb3 fehlt, SD-Slot hab ich jetzt 3, 100nF hab ich jetzt 4 übrig ... also immer noch lustig. HW-Stand immer noch 1.0 ( gab es überhaupt eine 1.1?)

* Mitte Jan. 2012, 10pol. beide Wannenstecker nicht dabei, Firmware war drauf, sofort funktioniert. 1 LED zuviel. Unproblematische Nachlieferung bei Reklamation (wegen der beiden Wannenstecker kam ein PAKET!).

* Ende Feb. 2012, Um die PHP-Scripte über öffentlichen Webserver zu betreiben muss mit SETGW die Gateway-Adresse des lokalen Routers eingetragen werden. Bei der NAT im Router sollte z.B. Port 8080 auf den internen Port 50290 umgeleitet werden, da manche Provider diesen Port für die Socket-Kommunikation nicht zulassen.

* Juli 2012, Bausatz vollständig, Nach Aufbau sofort den 7805 mit einem kleinen Kühlkörper versehen, da er sonst thermisch überlastet wird! hat weder auf LAN noch RS232 reagiert, musste erst Update einspielen (Download Pollin), danach funktionierte alles einwandfrei!

* Januar 2013, Bausatz vollständig, 7805 mit Kühlkörper versehen, nach Aufbau ohne Probleme funktioniert

* Februar 2013, Bausatz komplett, Aufbau ohne Probleme, 7805 nur leicht warm, LAN funktioniert, RS232 noch ohne Funktion.

* Oktober 2013, Bausatz komplett laut Stückliste, problemloser Aufbau, 7805 leicht warm am 10V DC. RS232 und LAN funktionierten auf Anhieb.

=== Erweiterungsplatine ===

Die nachfolgend genannten Änderungen sind in der Bauanleitung V1.1 mit Stand 07.12.2011 (Wichtig! Es gibt mehr als eine V1.1 ...) bereits berücksichtigt, R3 wird allerdings mit 3,6kΩ angegeben.

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5kΩ ersetzen mit 2kΩ
*R3 1,8K ersetzen mit 3,3kΩ
*R19 470kΩ ersetzen zu 470Ω
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache PNP! und mehr als 100mA)

'''ACHTUNG''' beim Anschluß eines LC-Displays an J5 (über I2C, PCF 8574): Vcc/5V liegt an Pin 1, GND an Pin 2 von J5. Es gibt etliche Displays mit abweichender Belegung Pin 1 GND und Pin 2 Vcc!

Auch beim Add-On gibt es fehlende oder falsche Bauteile im Bausatz und Fehler im Schaltplan und auf der Platine:

*Stand Feb. 2011: R2 wird mit 2,2kΩ und R3 wird mit 3,6kΩ ausgeliefert. Somit werden die 3,3 V richtig erzeugt. R19 hat 470Ω. Der ISP-Anschluß ist nicht vollständig durchgeschleift, es besteht keine Verbindung der RESET-Leitung zwischen ISP und ISP1 (Abhilfe: Drahtbrücke einlöten, [http://www.mikrocontroller.net/topic/161354#1600385 Quelle]).

*Stand Nov. 2011: bei mir ist die RESET-Leitung korrekt zw. ISP und ISP1 verbunden. Es gibt jetzt auch einen R24 (470Ohm) und R11 (1KOhm), der in der bei mir mitgelieferten Bauanleitung fehlt, in der zum Download (V1.1) angebotenen aber drin steht. Es wird immer noch der falsche Q1 BC548C (NPN) mitgeliefert. Das Schaltsymbol für einen PNP ist richtig im Schaltplan gezeichnet.

*Stand Dez. 2011: R24 (470Ω) kann mit 0Ω ersetzt und R11 (1kΩ) völlig weggelassen werden. Diese Widerstände bilden einen (eigentlich überflüssigen) Spannungsteiler in der MISO Leitung. Der Spannungsteiler hat allerdings auch eine Schutzfunktion, falls weitere Slaves am SPI-Bus hängen, die 5V-Pegel nutzen, z. B. ISP-Programmierer. (siehe [http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=1167&postid=9203 1284p: Board, ich oder beide verwirrt?])

*Sept'12: Bausatz mit Stecker anstelle einer Buchse ausgeliefert, 5mm anstelle von 3mm LED's dafür aber 3 Poti zuviel.

*Sept'12: Ebenfalls Bausatz mit Sub-D-Stecker statt Buchse ausgeliefert, 5mm anstelle von 3mm LED's und 3 Potis zuviel.

*Stand März 2013: Die Belegung der 25 pol. Sub-D-Buchse im Schaltplan der Anleitung V1.1 (und früher) ist falsch dargestellt. SCL und SDA des I2C-Busses liegen wie beim AVR-NET-IO Board auf Pin 2 bzw. 3 und nicht auf Pin 11 bzw. 12 der Buchse. Ein 1:1 verdrahtetes Kabel funktioniert.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

Links gehen nicht:
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== E2000-NET-IO-Multi-Control ===
Mti dem E2000-NET-IO-Multi-Control ist es möglich, die vom dem E2000-NET-IO-Designer erstellten Projekte zu öffnen und die AVR-NET-IO's zu steuern.

Die Anwendung liegt dem [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#E2000-NET-IO-Designer_.28Windows.5BXP.2F7.5D_.2F_Android.29 E2000-NET-IO-Designer] bei.

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

=== JAVA Lib ===
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.
http://son.ffdf-clan.de/?path=forumsthread&threadid=611

=== PHP ===
PHP Klasse zur Ansteuerung mit der Originalfirmware. (Opensource Lizenz)
http://blog.coldtobi.de/1_coldtobis_blog/archive/298_pollin_net-io_php_library.html

PHP Funktionen zum Ansteuern der Originalfirmware. (Free for All Lizenz)
http://defcon-cc.dyndns.org/wiki/index.php/Pollin_AVR-NetIO_PHP_Wrapper

== Clients für Smartphones ==

=== AVR NET IO Control (Windows Phone 7.5,7.8,8.0) ===

Freie App zur steuerung des AVR NET IO.

'''App im Market: [http://www.windowsphone.com/de-de/store/app/avr-net-io-controll/030d107f-9a27-4a62-ac8f-cb74e79c0500 AVR NET IO Control]'''
=== App NetIO (Windows Mobile 6.5) ===
Frei verfügbare App für Windows Mobile zur Ansteuerung mit der Orginalsoftware. Das HTC HD2 wird damit zur Fernsteuerung für das AVR Net-IO Board.
http://www.heesch.net/netio.aspx

=== NET-IO Control (Android) ===
Eine Application für das Android Betriebssystem zur Steuerung des AVR Net-IO Boards. Es ist möglich, alle Ausgänge zu steuern und alle Eingänge anzuzeigen. Die Analogen Eingänge können mit einem Berechnungsfaktor versehen werden. ''Geplant ist noch ein Offsetwert.'' Außerdem kann jedem analogen Wert eine Einheit zugeordnet werden. Die Ausgänge können in der neusten Version in einen Tastermodus gesetzt werden.

[[Datei:NET-IO-Control.png|200px]] [[Datei:NET-IO-Control2.png|200px]] [[Datei:NET-IO-Control3.png|200px]]

'''Trial-Version: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControlTRAIL Google-Play]'''

(In dieser Probe Version können nur 1 Output und 2 Inputs gesteuert werden)

'''Vollversion: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControl Google-Play]'''

(Kostet im Google-Play 3,00 €)

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== E2000-NET-IO-Designer (Windows[XP/7] / Android) ===
[[Datei:E2000-NET-IO-Designer.png|400px|right]]
Mit dem E2000-NET-IO-Designer ist es möglich, eine grafische Oberfläche für die NET-IOs von Pollin zu erstellen. Dafür werden Knöpfe, Texte und Anzeigebilder zur Verfügung gestellt. Jedes dieser Element kann "Aufgaben" übernehmen um die NET-IOs zu steuern oder einen Status des NET-IO anzuzeigen. Weitere Icons können von dem Benutzer selbst in den entsprechenden Ordner gelegt werden und in die Oberfläche eingebunden werden. Es können mehrere Seiten designt werden die durch einen selbst positionierten Knopf erreichbar sind. Die Android Application arbeitet somit im Fullscreen-Modus. Des weiteren ist es möglich, mehrere NET-IO's in einem Projekt zu benutzen. Nach dem erstellen der grafischen Oberfläche mit dem E2000-NET-IO-Designer, kann mit der Android APP das Projekt einfach gedownloaded werden. Dafür baut die APP eine Verbindung zum E2000-NET-IO-Designer auf und läd alle benötigten Dateien herunter (Achtung: Firewall-Einstellungen beachten). Die designten Oberflächen können außerdem noch mit der E2000-NET-IO-Multi-Control.exe auf dem Computer ausgeführt werden. Dadurch ist es Möglich, seine NET-IOs vom PC aus zu steuern über eine selbst designte Oberfläche.

Zum Ausführen des E2000-NET-IO-Designer muss .NET Framework 4.0 installiert sein und es muss eine Internetverbindung exisitieren.

'''Features:'''<ul>
<li>Grafische Oberfläche am PC erstellen</li>
<li>Verwendung von eigenen Button- und Hintergrundbildern</li>
<li>Designbare Anzeige von Digital- und Analogwerten</li>
<li>Steuern von mehreren AVR-NET-IO Boards</li>
<li>Unterstützung der E2000-NET-IO Firmware (mehere Boards gleichzeitig)</li>
<li>Designte Steuerungen können auf dem PC oder dem Handy ausgeführt werden (Android)</li>
<li>Schnelle Verbindung</li>
<li>Einfache übertragung auf das Handy durch Projekt Download</li>
</ul>

[http://www.elektronik2000.de/downloads.php?id=44 Download E2000-NET-IO-Designer]

[http://www.elektronik2000.de/hilfe/E2000Netdesigneruebersicht.html Online Hilfe]

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== NetIO ( iPhone & Android ) ===
<div style="float: left; margin-right: 20px">[[Datei:Netio_logo.png|70px]]</div>

Schöne universelle Fernbedienung für das Board (iOS / Android). Konfigurierbar über einen Browserbasierten Editor. 
Unterstützt TCP socket Verbindungen, kann http request absetzen und kann auch Webseiten einbinden (z.B. IP-Kameras). Kann mehrere
Boards gleichzeitig steuern! Einfach super schnell ins Projekt eingebaut... Es gibt Buttons (die auch als Taster konfiguriert werden können), Slider, Switches und einfache Labels. Dinge können geschaltet oder Daten ausgelesen und mit regex dargstellt werden.

<div style='float: right'>
[[Datei:Netio_TV.png|190px]]
[[Datei:Netio_iphone5.png|190px]]
[[Datei:NetIO_appflow.jpg|190px]]
</div>

 
AppStore Link: http://itunes.apple.com/app/netio/id464924297?mt=8 
Google Play Link: https://play.google.com/store/apps/details?id=com.luvago.netio 
Die gleiche Konfiguration kann auch mit einem [https://github.com/davideickhoff/NetIO-OSX-Dashboard-Widget OSX Widget] benutzt werden. 
Webseite: http://netio.davideickhoff.de

Hinweis: Man findet es unter "NetIO" im Store, im Icon selbst und in iTunes wird es als "Controller" angezeigt. 
Die eigene Konfiguration kann man mit dem [http://netio.davideickhoff.de/editor Online Editor] vorher am PC erstellen.
Eine fertige [http://netio.davideickhoff.de/editor/?config=pollin AVR-NET-IO Konfiguration] gibt es als funktionierendes Beispiel schon als Preset.

 
<div style='clear: both'></div>

=== AVR Net IO (iPhone) ===
[[Datei:AVRNetIO-Screenshot1.png|160px|rechts]]
Update 15.12.2011: Die Neue Version 1.3 ist seit gestern im AppStore. Fehlerkorrekturen und ein robusteres Handling machen die App nun zur universellen AVR-Net-IO-Steuerung.

Mit der [http://itunes.apple.com/de/app/avr-net-io/id460991760?mt=8 iPhone App AVR-Net-IO] kann das Board ferngesteuert werden. Die Fernsteuerung umfasst in der Version 1.1 folgende Funktionen: <ul>
<li>ADC-Werte zyklisch auslesen und darstellen</li>
<li>Digital-Inputs zyklisch darstellen</li>
<li>Digital-Outputs können über Buttons geschaltet werden. Die Werte der Digital-Outputs werden zuerst ausgelesen und zeigen den zuletzt gesetzten Wert an.</li>
<li>Terminal-Modus: Hier können beliebige AVR-Net-IO-Befehle eingegeben werden. Das Ergebnis wird 1:1 angezeigt, wie es vom Board kommt. Hilfreich für Tests bei Eigenentwicklungen und Konfigurationen.</li>
</ul>
 
Mehr Infos gibt's dazu direkt von den Entwicklern auf [http://www.facebook.com/pages/AVR-Net-IO/187799687958255?ref=nf AVR-net-IO Facebook-Page] oder direkt auf deren Homepage [http://www.ondics.de/apps/1001/ Homepage].
 
Hinweis: MIt der aktuellen Version 1.1 gibt es noch bei manchen Boards Probleme beim auslesen und anzeigen der ADC- und Digital-Werte. Das Terminal funzt problemlos. Die Entwickler kümmern sich gerade drum und haben einen baldigen Update versprochen.
 

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== E2000 - Logik ===

[[Datei:E2000-Logik-Bedienoberflaeche.jpg|500px|rechts]]

Anwenderfreundliche Logik-Software von Elektronik2000.de zur Steuerung des AVR-NET-IO. Der ATMEGA32 wird durch einen ATMEGA644 ersetzt und mit der E2000-Firmware beschrieben. Nun ist es möglich in der E2000-Logik Software eine Logikschaltung zu erstellen und diese auf das NET-IO-Board zu übertragen. Dort wird diese Schaltung simuliert. Dies funktioniert komplett ohne einen Computer.

Durch ein Erweiterungsboard von Elektronik2000.de ist es auch möglich, das Board ohne Internet laufen zu lassen eine RTC (RealTimeClock) übernimmt dabei die Uhrzeitgesteuerten Funktionen. Auf dieser Erweiterung ist auch ein EEPROM integriert, um Firmware-Updates über Netzwerk einzuspielen (in Zukunft). Diese Erweiterung bietet außerdem die Anbindung an das E2000-Bus-System, durch das es möglich ist das AVR-NET-IO-Board durch weitere Ein- und Ausgänge zu erweitern.

Das Designen von Schaltaufgaben wird in diesem Programm grafisch dargestellt, durch das ein einfaches Anpassen seiner Logikschaltungen möglich ist.

Eine Steuerung des E2000-NET-IO ist möglich durch den Intregrieten Webserver, die PC-Software (E2000-NET-IO Control) oder der Androidsoftware. All diese Können gleichzeitig auf das E2000-NET-IO zugreifen und Funktionen ausführen.

Weitere Informationen gibt es auf der Entwicklerseite: [http://www.elektronik2000.de Elektronik2000.de]

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere in der Datei ENC28J60.H:
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 
Um diesen Code mit einem Atmega1284P verwenden zu können, muss in der main.c in Zeile 38, "TIMSK" durch "TIMSK1" ersetzt werden.
Die Fusebits für den Atmega1284p ohne Bootloader sind:
lfuse=0xFF, hfuse=0xD9, efuse=0xFF

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== Avr ArtNET-Node ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt, dass viel Arbeit und Liebe in diesem Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-Systems, welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== OpenMLP ===
Auf openMCP basierender Port nach [http://avr.myluna.de LunaAVR] (GPL). Umfangreiche Funktionalität und direkte Anpassung an die Sprache. Abgespeckte Version auch auf Atmega32 lauffähig. Die Original-Dokumentation kann zum Großteil hergenommen werden. Einige Zusatzfeatures. Leichte Konfiguration und guter Einstieg für Anfänger und zum Verständnis der Serverfunktionalität.

[http://avr.myluna.de/doku.php?id=de:openmlp Artikelseite]
[http://forum.myluna.de/viewtopic.php?f=8&t=13 Forum]

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

=== AVR-Netino ===
[http://code.google.com/p/avr-netino/ Projekt und Software]

Arduino fürs Net-IO

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://avr.myluna.de/doku.php?id=de:openmlp LunaAVR openMLP ]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

AVR Net-IO Bausatz von Pollin

2013-10-11T00:50:40Z

Kbuchegg: /* Funktionsumfang der Originalsoftware */

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058], oder als aufgebautes Fertigmodul, Best.Nr. 810 073.

Einige Features: Ethernet-Platine mit ATmega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

[[Datei:AVR-NET-IO ADD-ON.JPG|thumb|right|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang)und Add-On-Board (oben, mit aufgelötetem RFM12-433-Modul, beides nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen zur Stromversorgung wurden durch Buchsen ersetzt.]]

== Technische Daten ==

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (L×B×H): 108×76×22 mm.

== Hardware ==
=== AVR-NET-IO ===

Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe.

=== Erweiterungsplatine ===

Seit Januar 2010 gibt es auch eine Erweiterungsplatine

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot-Empfang
* [[RFM12]] Funkmodul (nicht im Lieferumfang enthalten)

Eine Aufstellung bekannter Fehler findet sich weiter unten [[#Bekannte Fehler|Bekannte Fehler - Erweiterungplatine]]

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805 - (Vorsicht: Der LM317T ist rückseitig spannungsführend. Den Kühlkörper also keinesfalls an beide Spannungsregler anschließen!)
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
** Laut Spezifikation sind auch mehr als 1µF erlaubt. Selbst Atmel verwendet beim STK500 10µF. Dies führt keinesfalls dazu, dass die RS232 nicht mehr funktioniert.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen (R3)
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen (R6,R7)
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig. - Kondensator bei selbstbau-ISP empfehlenswert.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
*** ??? Ist dies nicht kontraproduktiv? Bei mir wurde durch D2-Bestückung die Eingangsspannung von ca. 5,2 V am LM317T auf ca. 4,6 V gedrückt, so dass am ENC28J60 nur ca. 2,6 V ankamen (außerhalb der lt. Datenblatt "Operating voltage range of 3.14V to 3.45V"). Man müsste also ein geregeltes Netzteil mit ca. 5,5 V anschließen um 5 und 3,3 V zu erzielen. Dann lieber den Verpolungsschutz durch andere Maßnahmen sicherstellen.
** Beim Betrieb von USB beachten, dass USB-Spezifikation keinesfalls 5V garantiert, sondern Spannung bis runter 4.4V erlaubt und dann u.U. durch den LM317 nicht mehr genügend Spannung am ENC anliegt. Das äußert sich so, dass zwar der Atmega einwandfrei funktioniert, die Ethernet-Kommunikation aber nicht oder nur sehr sporadisch.
* Ersatz des ATmega32 durch einen ATmega644 oder ATmega1284p mit mehr FLASH-Speicher.
** Der ATmega644 und auch der ATMega1284p sind nicht mit der Pollin-Firmware kompatibel
* 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die serielle Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal ein Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===
[[image:fuse_bits_avr_studio.jpg|thumb|right|250px|Einstellungen der Fuse-Bits mittels AVR Studio 4]]
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.
{{Absatz}}

==== Funktionsfähige Konfiguration - AVR-Prog ====

[[Bild:Avrprog.png|thumb|right|250px]]
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m
und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0.0/24 Subnetz ====

Betreibt man den PC nicht im 192.168.0.0/24 Subnetz, muss er wie folgt umkonfiguriert werden, oder die IP Adresse des Boards wird entsprechend angepasst. ( Siehe Handbuch Seite 14ff. Das ist meist sinnvoller und auch einfacher. )

Den PC vom normalen Netzwerk abstecken[1]. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Anmerkung von bitman:
[1] Dies ist spätestens ab Windows XP nicht mehr notwendig, wenn das Netz 192.168.0.0/24 noch frei ist. Dann kann man einfach den Client ''zusätzlich'' in diesem Netzwerk zusätzlich einbinden über Einstellungen/Netzwerkverbindungen/Lanverbindung/Eigenschaften/TCP-IP/Eigenschaften/Erweitert/IP-Adresse hinzufügen. Es werden dann eben mehrere IP-Adressen an den NIC gebunden.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FB NETMASK 
3FC - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

Wenn sich nach dem scheinbar erfolgreichem Einspielen der Firmware, später nichts tut, so sollte die Firmware mit gesetztem "FailSafe" in der mitgelieferten NetServer-Software nochmals Eingespielt werden.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Funktionsumfang der Originalsoftware ==
Die Originalsoftware ist sehr einfach gestrickt. Im AVR Net-IO läuft ein Programm, welches sowohl über die RS232 als auch über Ethernet angesprochen werden kann. Mit diesem Programm ist es möglich, alle Eingänge, alle Ausgänge anzusprechen, sowie die Konfiguration der Netzwerkeinstellungen zu verändern. Die Karte versteht dann folgende Befehle:
* SETPORT
* GETPORT
* SETIP
* GETIP
* SETMASK
* GETMASK
* SETGW
* GETGW
* GETSTATUS
* INITLCD
* WRITELCD
* CLEARLCD
* VERSION

Dazu gibt es ein auf Windows lauffähiges Programm, welches alternativ zu einem Terminalprogramm benutzt werden kann. Es zeigt den Status der Portpins an und diese lassen sich auch mit der Maus verändern. Die Messwerte der 4 analogen Eingänge werden ständig angezeigt, wobei es möglich ist, durch einstellbare Faktoren die internen Werte gleich in sinnvolle Einheiten umrechnen zu lassen. Diese Messwerte können auch in eine Datei geloggt werden.
Neben der Möglichkeit, alle Kommandos auch händisch einzugeben, wird das Windows Programm auch benötigt, um einen Firmware-Update der Net-IO Platine durchzuführen.
Alles in allem ist dieses Windows-Frontend aber mehr als Testumgebung anzusehen, um damit die Hardware in Betrieb zu nehmen. Für einen sinnvollen Dauereinsatz ist das Programm deutlich zu einfach und unflexibel gestrickt. Auch kann die grafische Aufbereitung der Anzeige- und Kontrollelemente nicht befriedigen.

== Bekannte Fehler ==
=== AVR-NET-IO ===

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]] 
Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt. Bei einem Bausatz gekauft 05/2013 ist dies ebenfalls noch der Fall.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

* Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10µF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1µF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Fertig gelötete Platine gekauft. µC war falsch im Sockel.

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert

* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel

* Bausatz August 10 gekauft: komplett und sofort funktioniert

* Bausatz Juli 10 gekauft: 2 Quarze mit 16 MHz geliefert, statt 1x 16MHz und 1x25MHz.

* Bausatz September 10 gekauft: hat sofort funktioniert. 1x 3,3k und 1x 10k Widerstand zuviel. Statt 100nF Kondensatoren wurden 1µF geliefert -> Platzprobleme auf der Platine durch grössere Bauform. LED grün.

* Bausatz Oktober 6 gekauft: alles funktioniert. LED grün statt rot.

* Fertigmodul Oktober 10 gekauft: Auf Anhieb alles funktioniert!

* Bausatz Oktober 10 gekauft: komplett und sofort funktioniert

* Bausatz November 10 gekauft: komplett und sofort funktioniert (sogar mit der neusten Pollin Firmware 1.03 schon drauf) LED grün statt rot.

* Bausatz November 10 gekauft. Nach Bezug neuer Feinst-Lötspitzen konnte ich ihn dann auch zusammenlöten. Es hat sofort alles funktioniert, obwohl ich nur 12V bzw. 9V Gleichspannung zur Verfügung hatte, und nicht sicher war, wieviel die Komponenten wirklich benötigen. Der Regler wird auch bei 9V Gleichspannungsversorgung noch sehr warm. Da muss auf jeden Fall ein Kühlkörper dran! Ich habe auch eine grüne LED bekommen, ist mir aber wurscht :-)

* Bausatz Dezember 10 gekauft: komplett und funktionierte sofort. Firmware 1.03, grüne LED (Ein Quarz und ein IC-Sockel zu viel)

* Bausatz Januar 2011 gekauft: nur genau die richtige Anzahl Teile dabei, Firmware 1.03, grüne LED, ging auf Anhieb

* 2x Bausatz Januar 2011 gekauft: beide grüne LED, und 1x doppelter Satz Jumper/Stiftleiste, 22PF und Anschlussklemmen. Rest vollständig und beide haben sofort nach zusammenbau funktioniert.

* Februar 2011: AVR-NET-IO: die Diode D5 fehlt, 10 µF gegen 1 µF für MAX232 getauscht, Flash im ATmega32 war programmiert, passende IP-Adr über serielle Schnittstelle eingestellt; ADD-ON: für R1 war 22Ω statt 0,2Ω beigelegt, durch richtigen ersetzt, Beschreibung der LED Bestückung mangelhaft / oe1smc

* Februar 2011: AVR-NET-IO: 1 Diode zuviel, 2 Spulen fehlen, LED grün. Die fehlenden Spulen wurden durch welche aus der Bastelkiste ersetzt - funktioniert. Der 7805 bekam einen kleinen Kühlkörper spendiert.

* Februar 2011: AVR-NET-IO: 2x 10k Widerstände fehlen. Dafür eine Diode zu viel.

* Ende Februar 2011: Zwei Bausaetze an jeweils zwei Adressen, alles in Ordnung.

* Ende März 2011: 2x 25 Mhz Quarz statt 1x16 u. 1x25 Mhz. LED fehlt. Bausatz funktioniert nach Tausch des Quarz den mir mein Freund oe9rsv aus seinem Fundus spendiert hat. Danke auch für die Hilfe beim Fehler suchen.

* Mitte 2010 gekauft: 1x 100nF fehlt

* Mitte Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, Pollin wollte, dass ich das ganze Paket zurückschicke für einen Austausch. Ein 51Ω zu viel. 16Mhz im Handel und 25Mhz vom alten Mobo ausgelötet. Läuft wunderbar.

* Anfang Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, nach kurzer Mail an Pollin (leider ohne Antwort) wurden diese nach ca. 1 Woche in einem Brief nachgeliefert.

* August 2011: alles 1a...

* August 2011: Platine fehlte -> in Nachlieferung

* 30 August 2011: alles 1a...

* 06 Sep. 2011: alles 1a...

* August 2011: 6 Stück bestellt, bei einem haben die 100nF Kondensatoren gefehlt, bei einem zwei LM317 statt 7805 und LM317. Angerufen, 3 Tage später Nachlieferung erhalten.

* Nov. 2011: '''Net_IO''' vollständig. Einspielen der Firmware 1.03 war erforderlich. Bei '''Add-On''' immer noch falscher Q1 BC548 (NPN) in Stückliste und Lieferung. BC327-40 oder BC328-40 (PNP) nachgefordert. R11 und R24 mitgeliefert, entsprechend Beschreibung V1.1 von Pollin's Download. Beiliegende Beschreibung war älter, ohne diese Widerstände.

* Ende Nov.2011, alle Teile dabei, Firmware war drauf, sofort funktioniert.

* Anfang Dez.2011, komplett bestückte Platine gekauft. Auf 7805 Kühlkörper gebaut, da er nach 1 Minute schon ausgestiegen ist (LED hat das Pumpen angefangen). Firmware 1.03 musste noch aufgespielt werden danach funktioniert alles einwandfrei. In Betrieb mit 10V DC

* Ende Dez.2011 2xNET-IO und 2xADD bestellt, 4 verschieden volle Kisten bekommen... WSL16 ist mit Verriegelung, geht nicht aufs Board, Jumper fehlen, Spannungsregler doppelt, Poti Löcher zu klein, lsb3 fehlt, SD-Slot hab ich jetzt 3, 100nF hab ich jetzt 4 übrig ... also immer noch lustig. HW-Stand immer noch 1.0 ( gab es überhaupt eine 1.1?)

* Mitte Jan. 2012, 10pol. beide Wannenstecker nicht dabei, Firmware war drauf, sofort funktioniert. 1 LED zuviel. Unproblematische Nachlieferung bei Reklamation (wegen der beiden Wannenstecker kam ein PAKET!).

* Ende Feb. 2012, Um die PHP-Scripte über öffentlichen Webserver zu betreiben muss mit SETGW die Gateway-Adresse des lokalen Routers eingetragen werden. Bei der NAT im Router sollte z.B. Port 8080 auf den internen Port 50290 umgeleitet werden, da manche Provider diesen Port für die Socket-Kommunikation nicht zulassen.

* Juli 2012, Bausatz vollständig, Nach Aufbau sofort den 7805 mit einem kleinen Kühlkörper versehen, da er sonst thermisch überlastet wird! hat weder auf LAN noch RS232 reagiert, musste erst Update einspielen (Download Pollin), danach funktionierte alles einwandfrei!

* Januar 2013, Bausatz vollständig, 7805 mit Kühlkörper versehen, nach Aufbau ohne Probleme funktioniert

* Februar 2013, Bausatz komplett, Aufbau ohne Probleme, 7805 nur leicht warm, LAN funktioniert, RS232 noch ohne Funktion.

* Oktober 2013, Bausatz komplett laut Stückliste, problemloser Aufbau, 7805 leicht warm am 10V DC. RS232 und LAN funktionierten auf Anhieb.

=== Erweiterungsplatine ===

Die nachfolgend genannten Änderungen sind in der Bauanleitung V1.1 mit Stand 07.12.2011 (Wichtig! Es gibt mehr als eine V1.1 ...) bereits berücksichtigt, R3 wird allerdings mit 3,6kΩ angegeben.

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5kΩ ersetzen mit 2kΩ
*R3 1,8K ersetzen mit 3,3kΩ
*R19 470kΩ ersetzen zu 470Ω
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache PNP! und mehr als 100mA)

'''ACHTUNG''' beim Anschluß eines LC-Displays an J5 (über I2C, PCF 8574): Vcc/5V liegt an Pin 1, GND an Pin 2 von J5. Es gibt etliche Displays mit abweichender Belegung Pin 1 GND und Pin 2 Vcc!

Auch beim Add-On gibt es fehlende oder falsche Bauteile im Bausatz und Fehler im Schaltplan und auf der Platine:

*Stand Feb. 2011: R2 wird mit 2,2kΩ und R3 wird mit 3,6kΩ ausgeliefert. Somit werden die 3,3 V richtig erzeugt. R19 hat 470Ω. Der ISP-Anschluß ist nicht vollständig durchgeschleift, es besteht keine Verbindung der RESET-Leitung zwischen ISP und ISP1 (Abhilfe: Drahtbrücke einlöten, [http://www.mikrocontroller.net/topic/161354#1600385 Quelle]).

*Stand Nov. 2011: bei mir ist die RESET-Leitung korrekt zw. ISP und ISP1 verbunden. Es gibt jetzt auch einen R24 (470Ohm) und R11 (1KOhm), der in der bei mir mitgelieferten Bauanleitung fehlt, in der zum Download (V1.1) angebotenen aber drin steht. Es wird immer noch der falsche Q1 BC548C (NPN) mitgeliefert. Das Schaltsymbol für einen PNP ist richtig im Schaltplan gezeichnet.

*Stand Dez. 2011: R24 (470Ω) kann mit 0Ω ersetzt und R11 (1kΩ) völlig weggelassen werden. Diese Widerstände bilden einen (eigentlich überflüssigen) Spannungsteiler in der MISO Leitung. Der Spannungsteiler hat allerdings auch eine Schutzfunktion, falls weitere Slaves am SPI-Bus hängen, die 5V-Pegel nutzen, z. B. ISP-Programmierer. (siehe [http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=1167&postid=9203 1284p: Board, ich oder beide verwirrt?])

*Sept'12: Bausatz mit Stecker anstelle einer Buchse ausgeliefert, 5mm anstelle von 3mm LED's dafür aber 3 Poti zuviel.

*Sept'12: Ebenfalls Bausatz mit Sub-D-Stecker statt Buchse ausgeliefert, 5mm anstelle von 3mm LED's und 3 Potis zuviel.

*Stand März 2013: Die Belegung der 25 pol. Sub-D-Buchse im Schaltplan der Anleitung V1.1 (und früher) ist falsch dargestellt. SCL und SDA des I2C-Busses liegen wie beim AVR-NET-IO Board auf Pin 2 bzw. 3 und nicht auf Pin 11 bzw. 12 der Buchse. Ein 1:1 verdrahtetes Kabel funktioniert.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

Links gehen nicht:
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== E2000-NET-IO-Multi-Control ===
Mti dem E2000-NET-IO-Multi-Control ist es möglich, die vom dem E2000-NET-IO-Designer erstellten Projekte zu öffnen und die AVR-NET-IO's zu steuern.

Die Anwendung liegt dem [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#E2000-NET-IO-Designer_.28Windows.5BXP.2F7.5D_.2F_Android.29 E2000-NET-IO-Designer] bei.

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

=== JAVA Lib ===
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.
http://son.ffdf-clan.de/?path=forumsthread&threadid=611

=== PHP ===
PHP Klasse zur Ansteuerung mit der Originalfirmware. (Opensource Lizenz)
http://blog.coldtobi.de/1_coldtobis_blog/archive/298_pollin_net-io_php_library.html

PHP Funktionen zum Ansteuern der Originalfirmware. (Free for All Lizenz)
http://defcon-cc.dyndns.org/wiki/index.php/Pollin_AVR-NetIO_PHP_Wrapper

== Clients für Smartphones ==

=== AVR NET IO Control (Windows Phone 7.5,7.8,8.0) ===

Freie App zur steuerung des AVR NET IO.

'''App im Market: [http://www.windowsphone.com/de-de/store/app/avr-net-io-controll/030d107f-9a27-4a62-ac8f-cb74e79c0500 AVR NET IO Control]'''
=== App NetIO (Windows Mobile 6.5) ===
Frei verfügbare App für Windows Mobile zur Ansteuerung mit der Orginalsoftware. Das HTC HD2 wird damit zur Fernsteuerung für das AVR Net-IO Board.
http://www.heesch.net/netio.aspx

=== NET-IO Control (Android) ===
Eine Application für das Android Betriebssystem zur Steuerung des AVR Net-IO Boards. Es ist möglich, alle Ausgänge zu steuern und alle Eingänge anzuzeigen. Die Analogen Eingänge können mit einem Berechnungsfaktor versehen werden. ''Geplant ist noch ein Offsetwert.'' Außerdem kann jedem analogen Wert eine Einheit zugeordnet werden. Die Ausgänge können in der neusten Version in einen Tastermodus gesetzt werden.

[[Datei:NET-IO-Control.png|200px]] [[Datei:NET-IO-Control2.png|200px]] [[Datei:NET-IO-Control3.png|200px]]

'''Trial-Version: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControlTRAIL Google-Play]'''

(In dieser Probe Version können nur 1 Output und 2 Inputs gesteuert werden)

'''Vollversion: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControl Google-Play]'''

(Kostet im Google-Play 3,00 €)

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== E2000-NET-IO-Designer (Windows[XP/7] / Android) ===
[[Datei:E2000-NET-IO-Designer.png|400px|right]]
Mit dem E2000-NET-IO-Designer ist es möglich, eine grafische Oberfläche für die NET-IOs von Pollin zu erstellen. Dafür werden Knöpfe, Texte und Anzeigebilder zur Verfügung gestellt. Jedes dieser Element kann "Aufgaben" übernehmen um die NET-IOs zu steuern oder einen Status des NET-IO anzuzeigen. Weitere Icons können von dem Benutzer selbst in den entsprechenden Ordner gelegt werden und in die Oberfläche eingebunden werden. Es können mehrere Seiten designt werden die durch einen selbst positionierten Knopf erreichbar sind. Die Android Application arbeitet somit im Fullscreen-Modus. Des weiteren ist es möglich, mehrere NET-IO's in einem Projekt zu benutzen. Nach dem erstellen der grafischen Oberfläche mit dem E2000-NET-IO-Designer, kann mit der Android APP das Projekt einfach gedownloaded werden. Dafür baut die APP eine Verbindung zum E2000-NET-IO-Designer auf und läd alle benötigten Dateien herunter (Achtung: Firewall-Einstellungen beachten). Die designten Oberflächen können außerdem noch mit der E2000-NET-IO-Multi-Control.exe auf dem Computer ausgeführt werden. Dadurch ist es Möglich, seine NET-IOs vom PC aus zu steuern über eine selbst designte Oberfläche.

Zum Ausführen des E2000-NET-IO-Designer muss .NET Framework 4.0 installiert sein und es muss eine Internetverbindung exisitieren.

'''Features:'''<ul>
<li>Grafische Oberfläche am PC erstellen</li>
<li>Verwendung von eigenen Button- und Hintergrundbildern</li>
<li>Designbare Anzeige von Digital- und Analogwerten</li>
<li>Steuern von mehreren AVR-NET-IO Boards</li>
<li>Unterstützung der E2000-NET-IO Firmware (mehere Boards gleichzeitig)</li>
<li>Designte Steuerungen können auf dem PC oder dem Handy ausgeführt werden (Android)</li>
<li>Schnelle Verbindung</li>
<li>Einfache übertragung auf das Handy durch Projekt Download</li>
</ul>

[http://www.elektronik2000.de/downloads.php?id=44 Download E2000-NET-IO-Designer]

[http://www.elektronik2000.de/hilfe/E2000Netdesigneruebersicht.html Online Hilfe]

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== NetIO ( iPhone & Android ) ===
<div style="float: left; margin-right: 20px">[[Datei:Netio_logo.png|70px]]</div>

Schöne universelle Fernbedienung für das Board (iOS / Android). Konfigurierbar über einen Browserbasierten Editor. 
Unterstützt TCP socket Verbindungen, kann http request absetzen und kann auch Webseiten einbinden (z.B. IP-Kameras). Kann mehrere
Boards gleichzeitig steuern! Einfach super schnell ins Projekt eingebaut... Es gibt Buttons (die auch als Taster konfiguriert werden können), Slider, Switches und einfache Labels. Dinge können geschaltet oder Daten ausgelesen und mit regex dargstellt werden.

<div style='float: right'>
[[Datei:Netio_TV.png|190px]]
[[Datei:Netio_iphone5.png|190px]]
[[Datei:NetIO_appflow.jpg|190px]]
</div>

 
AppStore Link: http://itunes.apple.com/app/netio/id464924297?mt=8 
Google Play Link: https://play.google.com/store/apps/details?id=com.luvago.netio 
Die gleiche Konfiguration kann auch mit einem [https://github.com/davideickhoff/NetIO-OSX-Dashboard-Widget OSX Widget] benutzt werden. 
Webseite: http://netio.davideickhoff.de

Hinweis: Man findet es unter "NetIO" im Store, im Icon selbst und in iTunes wird es als "Controller" angezeigt. 
Die eigene Konfiguration kann man mit dem [http://netio.davideickhoff.de/editor Online Editor] vorher am PC erstellen.
Eine fertige [http://netio.davideickhoff.de/editor/?config=pollin AVR-NET-IO Konfiguration] gibt es als funktionierendes Beispiel schon als Preset.

 
<div style='clear: both'></div>

=== AVR Net IO (iPhone) ===
[[Datei:AVRNetIO-Screenshot1.png|160px|rechts]]
Update 15.12.2011: Die Neue Version 1.3 ist seit gestern im AppStore. Fehlerkorrekturen und ein robusteres Handling machen die App nun zur universellen AVR-Net-IO-Steuerung.

Mit der [http://itunes.apple.com/de/app/avr-net-io/id460991760?mt=8 iPhone App AVR-Net-IO] kann das Board ferngesteuert werden. Die Fernsteuerung umfasst in der Version 1.1 folgende Funktionen: <ul>
<li>ADC-Werte zyklisch auslesen und darstellen</li>
<li>Digital-Inputs zyklisch darstellen</li>
<li>Digital-Outputs können über Buttons geschaltet werden. Die Werte der Digital-Outputs werden zuerst ausgelesen und zeigen den zuletzt gesetzten Wert an.</li>
<li>Terminal-Modus: Hier können beliebige AVR-Net-IO-Befehle eingegeben werden. Das Ergebnis wird 1:1 angezeigt, wie es vom Board kommt. Hilfreich für Tests bei Eigenentwicklungen und Konfigurationen.</li>
</ul>
 
Mehr Infos gibt's dazu direkt von den Entwicklern auf [http://www.facebook.com/pages/AVR-Net-IO/187799687958255?ref=nf AVR-net-IO Facebook-Page] oder direkt auf deren Homepage [http://www.ondics.de/apps/1001/ Homepage].
 
Hinweis: MIt der aktuellen Version 1.1 gibt es noch bei manchen Boards Probleme beim auslesen und anzeigen der ADC- und Digital-Werte. Das Terminal funzt problemlos. Die Entwickler kümmern sich gerade drum und haben einen baldigen Update versprochen.
 

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== E2000 - Logik ===

[[Datei:E2000-Logik-Bedienoberflaeche.jpg|500px|rechts]]

Anwenderfreundliche Logik-Software von Elektronik2000.de zur Steuerung des AVR-NET-IO. Der ATMEGA32 wird durch einen ATMEGA644 ersetzt und mit der E2000-Firmware beschrieben. Nun ist es möglich in der E2000-Logik Software eine Logikschaltung zu erstellen und diese auf das NET-IO-Board zu übertragen. Dort wird diese Schaltung simuliert. Dies funktioniert komplett ohne einen Computer.

Durch ein Erweiterungsboard von Elektronik2000.de ist es auch möglich, das Board ohne Internet laufen zu lassen eine RTC (RealTimeClock) übernimmt dabei die Uhrzeitgesteuerten Funktionen. Auf dieser Erweiterung ist auch ein EEPROM integriert, um Firmware-Updates über Netzwerk einzuspielen (in Zukunft). Diese Erweiterung bietet außerdem die Anbindung an das E2000-Bus-System, durch das es möglich ist das AVR-NET-IO-Board durch weitere Ein- und Ausgänge zu erweitern.

Das Designen von Schaltaufgaben wird in diesem Programm grafisch dargestellt, durch das ein einfaches Anpassen seiner Logikschaltungen möglich ist.

Eine Steuerung des E2000-NET-IO ist möglich durch den Intregrieten Webserver, die PC-Software (E2000-NET-IO Control) oder der Androidsoftware. All diese Können gleichzeitig auf das E2000-NET-IO zugreifen und Funktionen ausführen.

Weitere Informationen gibt es auf der Entwicklerseite: [http://www.elektronik2000.de Elektronik2000.de]

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere in der Datei ENC28J60.H:
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 
Um diesen Code mit einem Atmega1284P verwenden zu können, muss in der main.c in Zeile 38, "TIMSK" durch "TIMSK1" ersetzt werden.
Die Fusebits für den Atmega1284p ohne Bootloader sind:
lfuse=0xFF, hfuse=0xD9, efuse=0xFF

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== Avr ArtNET-Node ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt, dass viel Arbeit und Liebe in diesem Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-Systems, welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== OpenMLP ===
Auf openMCP basierender Port nach [http://avr.myluna.de LunaAVR] (GPL). Umfangreiche Funktionalität und direkte Anpassung an die Sprache. Abgespeckte Version auch auf Atmega32 lauffähig. Die Original-Dokumentation kann zum Großteil hergenommen werden. Einige Zusatzfeatures. Leichte Konfiguration und guter Einstieg für Anfänger und zum Verständnis der Serverfunktionalität.

[http://avr.myluna.de/doku.php?id=de:openmlp Artikelseite]
[http://forum.myluna.de/viewtopic.php?f=8&t=13 Forum]

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

=== AVR-Netino ===
[http://code.google.com/p/avr-netino/ Projekt und Software]

Arduino fürs Net-IO

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://avr.myluna.de/doku.php?id=de:openmlp LunaAVR openMLP ]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

AVR Net-IO Bausatz von Pollin

2013-10-11T00:49:40Z

Kbuchegg: /* Inbetriebnahme der Originalsoftware */

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058], oder als aufgebautes Fertigmodul, Best.Nr. 810 073.

Einige Features: Ethernet-Platine mit ATmega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

[[Datei:AVR-NET-IO ADD-ON.JPG|thumb|right|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang)und Add-On-Board (oben, mit aufgelötetem RFM12-433-Modul, beides nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen zur Stromversorgung wurden durch Buchsen ersetzt.]]

== Technische Daten ==

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (L×B×H): 108×76×22 mm.

== Hardware ==
=== AVR-NET-IO ===

Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe.

=== Erweiterungsplatine ===

Seit Januar 2010 gibt es auch eine Erweiterungsplatine

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot-Empfang
* [[RFM12]] Funkmodul (nicht im Lieferumfang enthalten)

Eine Aufstellung bekannter Fehler findet sich weiter unten [[#Bekannte Fehler|Bekannte Fehler - Erweiterungplatine]]

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805 - (Vorsicht: Der LM317T ist rückseitig spannungsführend. Den Kühlkörper also keinesfalls an beide Spannungsregler anschließen!)
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
** Laut Spezifikation sind auch mehr als 1µF erlaubt. Selbst Atmel verwendet beim STK500 10µF. Dies führt keinesfalls dazu, dass die RS232 nicht mehr funktioniert.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen (R3)
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen (R6,R7)
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig. - Kondensator bei selbstbau-ISP empfehlenswert.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
*** ??? Ist dies nicht kontraproduktiv? Bei mir wurde durch D2-Bestückung die Eingangsspannung von ca. 5,2 V am LM317T auf ca. 4,6 V gedrückt, so dass am ENC28J60 nur ca. 2,6 V ankamen (außerhalb der lt. Datenblatt "Operating voltage range of 3.14V to 3.45V"). Man müsste also ein geregeltes Netzteil mit ca. 5,5 V anschließen um 5 und 3,3 V zu erzielen. Dann lieber den Verpolungsschutz durch andere Maßnahmen sicherstellen.
** Beim Betrieb von USB beachten, dass USB-Spezifikation keinesfalls 5V garantiert, sondern Spannung bis runter 4.4V erlaubt und dann u.U. durch den LM317 nicht mehr genügend Spannung am ENC anliegt. Das äußert sich so, dass zwar der Atmega einwandfrei funktioniert, die Ethernet-Kommunikation aber nicht oder nur sehr sporadisch.
* Ersatz des ATmega32 durch einen ATmega644 oder ATmega1284p mit mehr FLASH-Speicher.
** Der ATmega644 und auch der ATMega1284p sind nicht mit der Pollin-Firmware kompatibel
* 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die serielle Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal ein Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===
[[image:fuse_bits_avr_studio.jpg|thumb|right|250px|Einstellungen der Fuse-Bits mittels AVR Studio 4]]
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.
{{Absatz}}

==== Funktionsfähige Konfiguration - AVR-Prog ====

[[Bild:Avrprog.png|thumb|right|250px]]
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m
und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0.0/24 Subnetz ====

Betreibt man den PC nicht im 192.168.0.0/24 Subnetz, muss er wie folgt umkonfiguriert werden, oder die IP Adresse des Boards wird entsprechend angepasst. ( Siehe Handbuch Seite 14ff. Das ist meist sinnvoller und auch einfacher. )

Den PC vom normalen Netzwerk abstecken[1]. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Anmerkung von bitman:
[1] Dies ist spätestens ab Windows XP nicht mehr notwendig, wenn das Netz 192.168.0.0/24 noch frei ist. Dann kann man einfach den Client ''zusätzlich'' in diesem Netzwerk zusätzlich einbinden über Einstellungen/Netzwerkverbindungen/Lanverbindung/Eigenschaften/TCP-IP/Eigenschaften/Erweitert/IP-Adresse hinzufügen. Es werden dann eben mehrere IP-Adressen an den NIC gebunden.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FB NETMASK 
3FC - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

Wenn sich nach dem scheinbar erfolgreichem Einspielen der Firmware, später nichts tut, so sollte die Firmware mit gesetztem "FailSafe" in der mitgelieferten NetServer-Software nochmals Eingespielt werden.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Funktionsumfang der Originalsoftware ==
Die Originalsoftware ist sehr einfach gestrickt. Im AVR Net-IO läuft ein Programm, welches sowohl über die RS232 als auch über Ethernet angesprochen werden kann. Mit diesem Programm ist es möglich, alle Eingänge, alle Ausgänge anzusprechen, sowie die Konfiguration der Netzwerkeinstellungen zu verändern. Die Karte versteht dann folgende Befehle:
* SETPORT
* GETPORT
* SETIP
* GETIP
* SETMASK
* GETMASK
* SETGW
* GETGW
* GETSTATUS
* INITLCD
* WRITELCD
* CLEARLCD
* VERSION

Dazu gibt es ein auf Windows lauffähiges Programm, welches alternativ zu einem Terminalprogramm benutzt werden kann. Es zeigt den Status der Portpins an und diese lassen sich auch mit der Maus verändern. Die Messwerte der 4 analogen Eingänge werden ständig angezeigt, wobei es möglich ist, durch einstellbare Faktoren die internen Werte gleich in sinnvolle Einheiten umrechnen zu lassen. Diese Messwerte können auch in eine Datei geloggt werden.
Neben der Möglichkeit, alle Kommandos auch händisch einzugeben, wird das Windows Programm auch benötigt, um einen Firmware-Update der Net-IO Platine durchzuführen.
Alles in allem ist dieses Windows-Frontend aber mehr als Testumgebung anzusehen, um damit die Hardware in Betrieb zu nehmen. Für einen sinnvollen Dauereinsatz ist das Programm deutlich zu einfach und unflexibel gestrickt.

== Bekannte Fehler ==
=== AVR-NET-IO ===

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]] 
Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt. Bei einem Bausatz gekauft 05/2013 ist dies ebenfalls noch der Fall.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

* Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10µF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1µF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Fertig gelötete Platine gekauft. µC war falsch im Sockel.

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert

* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel

* Bausatz August 10 gekauft: komplett und sofort funktioniert

* Bausatz Juli 10 gekauft: 2 Quarze mit 16 MHz geliefert, statt 1x 16MHz und 1x25MHz.

* Bausatz September 10 gekauft: hat sofort funktioniert. 1x 3,3k und 1x 10k Widerstand zuviel. Statt 100nF Kondensatoren wurden 1µF geliefert -> Platzprobleme auf der Platine durch grössere Bauform. LED grün.

* Bausatz Oktober 6 gekauft: alles funktioniert. LED grün statt rot.

* Fertigmodul Oktober 10 gekauft: Auf Anhieb alles funktioniert!

* Bausatz Oktober 10 gekauft: komplett und sofort funktioniert

* Bausatz November 10 gekauft: komplett und sofort funktioniert (sogar mit der neusten Pollin Firmware 1.03 schon drauf) LED grün statt rot.

* Bausatz November 10 gekauft. Nach Bezug neuer Feinst-Lötspitzen konnte ich ihn dann auch zusammenlöten. Es hat sofort alles funktioniert, obwohl ich nur 12V bzw. 9V Gleichspannung zur Verfügung hatte, und nicht sicher war, wieviel die Komponenten wirklich benötigen. Der Regler wird auch bei 9V Gleichspannungsversorgung noch sehr warm. Da muss auf jeden Fall ein Kühlkörper dran! Ich habe auch eine grüne LED bekommen, ist mir aber wurscht :-)

* Bausatz Dezember 10 gekauft: komplett und funktionierte sofort. Firmware 1.03, grüne LED (Ein Quarz und ein IC-Sockel zu viel)

* Bausatz Januar 2011 gekauft: nur genau die richtige Anzahl Teile dabei, Firmware 1.03, grüne LED, ging auf Anhieb

* 2x Bausatz Januar 2011 gekauft: beide grüne LED, und 1x doppelter Satz Jumper/Stiftleiste, 22PF und Anschlussklemmen. Rest vollständig und beide haben sofort nach zusammenbau funktioniert.

* Februar 2011: AVR-NET-IO: die Diode D5 fehlt, 10 µF gegen 1 µF für MAX232 getauscht, Flash im ATmega32 war programmiert, passende IP-Adr über serielle Schnittstelle eingestellt; ADD-ON: für R1 war 22Ω statt 0,2Ω beigelegt, durch richtigen ersetzt, Beschreibung der LED Bestückung mangelhaft / oe1smc

* Februar 2011: AVR-NET-IO: 1 Diode zuviel, 2 Spulen fehlen, LED grün. Die fehlenden Spulen wurden durch welche aus der Bastelkiste ersetzt - funktioniert. Der 7805 bekam einen kleinen Kühlkörper spendiert.

* Februar 2011: AVR-NET-IO: 2x 10k Widerstände fehlen. Dafür eine Diode zu viel.

* Ende Februar 2011: Zwei Bausaetze an jeweils zwei Adressen, alles in Ordnung.

* Ende März 2011: 2x 25 Mhz Quarz statt 1x16 u. 1x25 Mhz. LED fehlt. Bausatz funktioniert nach Tausch des Quarz den mir mein Freund oe9rsv aus seinem Fundus spendiert hat. Danke auch für die Hilfe beim Fehler suchen.

* Mitte 2010 gekauft: 1x 100nF fehlt

* Mitte Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, Pollin wollte, dass ich das ganze Paket zurückschicke für einen Austausch. Ein 51Ω zu viel. 16Mhz im Handel und 25Mhz vom alten Mobo ausgelötet. Läuft wunderbar.

* Anfang Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, nach kurzer Mail an Pollin (leider ohne Antwort) wurden diese nach ca. 1 Woche in einem Brief nachgeliefert.

* August 2011: alles 1a...

* August 2011: Platine fehlte -> in Nachlieferung

* 30 August 2011: alles 1a...

* 06 Sep. 2011: alles 1a...

* August 2011: 6 Stück bestellt, bei einem haben die 100nF Kondensatoren gefehlt, bei einem zwei LM317 statt 7805 und LM317. Angerufen, 3 Tage später Nachlieferung erhalten.

* Nov. 2011: '''Net_IO''' vollständig. Einspielen der Firmware 1.03 war erforderlich. Bei '''Add-On''' immer noch falscher Q1 BC548 (NPN) in Stückliste und Lieferung. BC327-40 oder BC328-40 (PNP) nachgefordert. R11 und R24 mitgeliefert, entsprechend Beschreibung V1.1 von Pollin's Download. Beiliegende Beschreibung war älter, ohne diese Widerstände.

* Ende Nov.2011, alle Teile dabei, Firmware war drauf, sofort funktioniert.

* Anfang Dez.2011, komplett bestückte Platine gekauft. Auf 7805 Kühlkörper gebaut, da er nach 1 Minute schon ausgestiegen ist (LED hat das Pumpen angefangen). Firmware 1.03 musste noch aufgespielt werden danach funktioniert alles einwandfrei. In Betrieb mit 10V DC

* Ende Dez.2011 2xNET-IO und 2xADD bestellt, 4 verschieden volle Kisten bekommen... WSL16 ist mit Verriegelung, geht nicht aufs Board, Jumper fehlen, Spannungsregler doppelt, Poti Löcher zu klein, lsb3 fehlt, SD-Slot hab ich jetzt 3, 100nF hab ich jetzt 4 übrig ... also immer noch lustig. HW-Stand immer noch 1.0 ( gab es überhaupt eine 1.1?)

* Mitte Jan. 2012, 10pol. beide Wannenstecker nicht dabei, Firmware war drauf, sofort funktioniert. 1 LED zuviel. Unproblematische Nachlieferung bei Reklamation (wegen der beiden Wannenstecker kam ein PAKET!).

* Ende Feb. 2012, Um die PHP-Scripte über öffentlichen Webserver zu betreiben muss mit SETGW die Gateway-Adresse des lokalen Routers eingetragen werden. Bei der NAT im Router sollte z.B. Port 8080 auf den internen Port 50290 umgeleitet werden, da manche Provider diesen Port für die Socket-Kommunikation nicht zulassen.

* Juli 2012, Bausatz vollständig, Nach Aufbau sofort den 7805 mit einem kleinen Kühlkörper versehen, da er sonst thermisch überlastet wird! hat weder auf LAN noch RS232 reagiert, musste erst Update einspielen (Download Pollin), danach funktionierte alles einwandfrei!

* Januar 2013, Bausatz vollständig, 7805 mit Kühlkörper versehen, nach Aufbau ohne Probleme funktioniert

* Februar 2013, Bausatz komplett, Aufbau ohne Probleme, 7805 nur leicht warm, LAN funktioniert, RS232 noch ohne Funktion.

* Oktober 2013, Bausatz komplett laut Stückliste, problemloser Aufbau, 7805 leicht warm am 10V DC. RS232 und LAN funktionierten auf Anhieb.

=== Erweiterungsplatine ===

Die nachfolgend genannten Änderungen sind in der Bauanleitung V1.1 mit Stand 07.12.2011 (Wichtig! Es gibt mehr als eine V1.1 ...) bereits berücksichtigt, R3 wird allerdings mit 3,6kΩ angegeben.

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5kΩ ersetzen mit 2kΩ
*R3 1,8K ersetzen mit 3,3kΩ
*R19 470kΩ ersetzen zu 470Ω
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache PNP! und mehr als 100mA)

'''ACHTUNG''' beim Anschluß eines LC-Displays an J5 (über I2C, PCF 8574): Vcc/5V liegt an Pin 1, GND an Pin 2 von J5. Es gibt etliche Displays mit abweichender Belegung Pin 1 GND und Pin 2 Vcc!

Auch beim Add-On gibt es fehlende oder falsche Bauteile im Bausatz und Fehler im Schaltplan und auf der Platine:

*Stand Feb. 2011: R2 wird mit 2,2kΩ und R3 wird mit 3,6kΩ ausgeliefert. Somit werden die 3,3 V richtig erzeugt. R19 hat 470Ω. Der ISP-Anschluß ist nicht vollständig durchgeschleift, es besteht keine Verbindung der RESET-Leitung zwischen ISP und ISP1 (Abhilfe: Drahtbrücke einlöten, [http://www.mikrocontroller.net/topic/161354#1600385 Quelle]).

*Stand Nov. 2011: bei mir ist die RESET-Leitung korrekt zw. ISP und ISP1 verbunden. Es gibt jetzt auch einen R24 (470Ohm) und R11 (1KOhm), der in der bei mir mitgelieferten Bauanleitung fehlt, in der zum Download (V1.1) angebotenen aber drin steht. Es wird immer noch der falsche Q1 BC548C (NPN) mitgeliefert. Das Schaltsymbol für einen PNP ist richtig im Schaltplan gezeichnet.

*Stand Dez. 2011: R24 (470Ω) kann mit 0Ω ersetzt und R11 (1kΩ) völlig weggelassen werden. Diese Widerstände bilden einen (eigentlich überflüssigen) Spannungsteiler in der MISO Leitung. Der Spannungsteiler hat allerdings auch eine Schutzfunktion, falls weitere Slaves am SPI-Bus hängen, die 5V-Pegel nutzen, z. B. ISP-Programmierer. (siehe [http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=1167&postid=9203 1284p: Board, ich oder beide verwirrt?])

*Sept'12: Bausatz mit Stecker anstelle einer Buchse ausgeliefert, 5mm anstelle von 3mm LED's dafür aber 3 Poti zuviel.

*Sept'12: Ebenfalls Bausatz mit Sub-D-Stecker statt Buchse ausgeliefert, 5mm anstelle von 3mm LED's und 3 Potis zuviel.

*Stand März 2013: Die Belegung der 25 pol. Sub-D-Buchse im Schaltplan der Anleitung V1.1 (und früher) ist falsch dargestellt. SCL und SDA des I2C-Busses liegen wie beim AVR-NET-IO Board auf Pin 2 bzw. 3 und nicht auf Pin 11 bzw. 12 der Buchse. Ein 1:1 verdrahtetes Kabel funktioniert.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

Links gehen nicht:
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== E2000-NET-IO-Multi-Control ===
Mti dem E2000-NET-IO-Multi-Control ist es möglich, die vom dem E2000-NET-IO-Designer erstellten Projekte zu öffnen und die AVR-NET-IO's zu steuern.

Die Anwendung liegt dem [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#E2000-NET-IO-Designer_.28Windows.5BXP.2F7.5D_.2F_Android.29 E2000-NET-IO-Designer] bei.

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

=== JAVA Lib ===
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.
http://son.ffdf-clan.de/?path=forumsthread&threadid=611

=== PHP ===
PHP Klasse zur Ansteuerung mit der Originalfirmware. (Opensource Lizenz)
http://blog.coldtobi.de/1_coldtobis_blog/archive/298_pollin_net-io_php_library.html

PHP Funktionen zum Ansteuern der Originalfirmware. (Free for All Lizenz)
http://defcon-cc.dyndns.org/wiki/index.php/Pollin_AVR-NetIO_PHP_Wrapper

== Clients für Smartphones ==

=== AVR NET IO Control (Windows Phone 7.5,7.8,8.0) ===

Freie App zur steuerung des AVR NET IO.

'''App im Market: [http://www.windowsphone.com/de-de/store/app/avr-net-io-controll/030d107f-9a27-4a62-ac8f-cb74e79c0500 AVR NET IO Control]'''
=== App NetIO (Windows Mobile 6.5) ===
Frei verfügbare App für Windows Mobile zur Ansteuerung mit der Orginalsoftware. Das HTC HD2 wird damit zur Fernsteuerung für das AVR Net-IO Board.
http://www.heesch.net/netio.aspx

=== NET-IO Control (Android) ===
Eine Application für das Android Betriebssystem zur Steuerung des AVR Net-IO Boards. Es ist möglich, alle Ausgänge zu steuern und alle Eingänge anzuzeigen. Die Analogen Eingänge können mit einem Berechnungsfaktor versehen werden. ''Geplant ist noch ein Offsetwert.'' Außerdem kann jedem analogen Wert eine Einheit zugeordnet werden. Die Ausgänge können in der neusten Version in einen Tastermodus gesetzt werden.

[[Datei:NET-IO-Control.png|200px]] [[Datei:NET-IO-Control2.png|200px]] [[Datei:NET-IO-Control3.png|200px]]

'''Trial-Version: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControlTRAIL Google-Play]'''

(In dieser Probe Version können nur 1 Output und 2 Inputs gesteuert werden)

'''Vollversion: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControl Google-Play]'''

(Kostet im Google-Play 3,00 €)

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== E2000-NET-IO-Designer (Windows[XP/7] / Android) ===
[[Datei:E2000-NET-IO-Designer.png|400px|right]]
Mit dem E2000-NET-IO-Designer ist es möglich, eine grafische Oberfläche für die NET-IOs von Pollin zu erstellen. Dafür werden Knöpfe, Texte und Anzeigebilder zur Verfügung gestellt. Jedes dieser Element kann "Aufgaben" übernehmen um die NET-IOs zu steuern oder einen Status des NET-IO anzuzeigen. Weitere Icons können von dem Benutzer selbst in den entsprechenden Ordner gelegt werden und in die Oberfläche eingebunden werden. Es können mehrere Seiten designt werden die durch einen selbst positionierten Knopf erreichbar sind. Die Android Application arbeitet somit im Fullscreen-Modus. Des weiteren ist es möglich, mehrere NET-IO's in einem Projekt zu benutzen. Nach dem erstellen der grafischen Oberfläche mit dem E2000-NET-IO-Designer, kann mit der Android APP das Projekt einfach gedownloaded werden. Dafür baut die APP eine Verbindung zum E2000-NET-IO-Designer auf und läd alle benötigten Dateien herunter (Achtung: Firewall-Einstellungen beachten). Die designten Oberflächen können außerdem noch mit der E2000-NET-IO-Multi-Control.exe auf dem Computer ausgeführt werden. Dadurch ist es Möglich, seine NET-IOs vom PC aus zu steuern über eine selbst designte Oberfläche.

Zum Ausführen des E2000-NET-IO-Designer muss .NET Framework 4.0 installiert sein und es muss eine Internetverbindung exisitieren.

'''Features:'''<ul>
<li>Grafische Oberfläche am PC erstellen</li>
<li>Verwendung von eigenen Button- und Hintergrundbildern</li>
<li>Designbare Anzeige von Digital- und Analogwerten</li>
<li>Steuern von mehreren AVR-NET-IO Boards</li>
<li>Unterstützung der E2000-NET-IO Firmware (mehere Boards gleichzeitig)</li>
<li>Designte Steuerungen können auf dem PC oder dem Handy ausgeführt werden (Android)</li>
<li>Schnelle Verbindung</li>
<li>Einfache übertragung auf das Handy durch Projekt Download</li>
</ul>

[http://www.elektronik2000.de/downloads.php?id=44 Download E2000-NET-IO-Designer]

[http://www.elektronik2000.de/hilfe/E2000Netdesigneruebersicht.html Online Hilfe]

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== NetIO ( iPhone & Android ) ===
<div style="float: left; margin-right: 20px">[[Datei:Netio_logo.png|70px]]</div>

Schöne universelle Fernbedienung für das Board (iOS / Android). Konfigurierbar über einen Browserbasierten Editor. 
Unterstützt TCP socket Verbindungen, kann http request absetzen und kann auch Webseiten einbinden (z.B. IP-Kameras). Kann mehrere
Boards gleichzeitig steuern! Einfach super schnell ins Projekt eingebaut... Es gibt Buttons (die auch als Taster konfiguriert werden können), Slider, Switches und einfache Labels. Dinge können geschaltet oder Daten ausgelesen und mit regex dargstellt werden.

<div style='float: right'>
[[Datei:Netio_TV.png|190px]]
[[Datei:Netio_iphone5.png|190px]]
[[Datei:NetIO_appflow.jpg|190px]]
</div>

 
AppStore Link: http://itunes.apple.com/app/netio/id464924297?mt=8 
Google Play Link: https://play.google.com/store/apps/details?id=com.luvago.netio 
Die gleiche Konfiguration kann auch mit einem [https://github.com/davideickhoff/NetIO-OSX-Dashboard-Widget OSX Widget] benutzt werden. 
Webseite: http://netio.davideickhoff.de

Hinweis: Man findet es unter "NetIO" im Store, im Icon selbst und in iTunes wird es als "Controller" angezeigt. 
Die eigene Konfiguration kann man mit dem [http://netio.davideickhoff.de/editor Online Editor] vorher am PC erstellen.
Eine fertige [http://netio.davideickhoff.de/editor/?config=pollin AVR-NET-IO Konfiguration] gibt es als funktionierendes Beispiel schon als Preset.

 
<div style='clear: both'></div>

=== AVR Net IO (iPhone) ===
[[Datei:AVRNetIO-Screenshot1.png|160px|rechts]]
Update 15.12.2011: Die Neue Version 1.3 ist seit gestern im AppStore. Fehlerkorrekturen und ein robusteres Handling machen die App nun zur universellen AVR-Net-IO-Steuerung.

Mit der [http://itunes.apple.com/de/app/avr-net-io/id460991760?mt=8 iPhone App AVR-Net-IO] kann das Board ferngesteuert werden. Die Fernsteuerung umfasst in der Version 1.1 folgende Funktionen: <ul>
<li>ADC-Werte zyklisch auslesen und darstellen</li>
<li>Digital-Inputs zyklisch darstellen</li>
<li>Digital-Outputs können über Buttons geschaltet werden. Die Werte der Digital-Outputs werden zuerst ausgelesen und zeigen den zuletzt gesetzten Wert an.</li>
<li>Terminal-Modus: Hier können beliebige AVR-Net-IO-Befehle eingegeben werden. Das Ergebnis wird 1:1 angezeigt, wie es vom Board kommt. Hilfreich für Tests bei Eigenentwicklungen und Konfigurationen.</li>
</ul>
 
Mehr Infos gibt's dazu direkt von den Entwicklern auf [http://www.facebook.com/pages/AVR-Net-IO/187799687958255?ref=nf AVR-net-IO Facebook-Page] oder direkt auf deren Homepage [http://www.ondics.de/apps/1001/ Homepage].
 
Hinweis: MIt der aktuellen Version 1.1 gibt es noch bei manchen Boards Probleme beim auslesen und anzeigen der ADC- und Digital-Werte. Das Terminal funzt problemlos. Die Entwickler kümmern sich gerade drum und haben einen baldigen Update versprochen.
 

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== E2000 - Logik ===

[[Datei:E2000-Logik-Bedienoberflaeche.jpg|500px|rechts]]

Anwenderfreundliche Logik-Software von Elektronik2000.de zur Steuerung des AVR-NET-IO. Der ATMEGA32 wird durch einen ATMEGA644 ersetzt und mit der E2000-Firmware beschrieben. Nun ist es möglich in der E2000-Logik Software eine Logikschaltung zu erstellen und diese auf das NET-IO-Board zu übertragen. Dort wird diese Schaltung simuliert. Dies funktioniert komplett ohne einen Computer.

Durch ein Erweiterungsboard von Elektronik2000.de ist es auch möglich, das Board ohne Internet laufen zu lassen eine RTC (RealTimeClock) übernimmt dabei die Uhrzeitgesteuerten Funktionen. Auf dieser Erweiterung ist auch ein EEPROM integriert, um Firmware-Updates über Netzwerk einzuspielen (in Zukunft). Diese Erweiterung bietet außerdem die Anbindung an das E2000-Bus-System, durch das es möglich ist das AVR-NET-IO-Board durch weitere Ein- und Ausgänge zu erweitern.

Das Designen von Schaltaufgaben wird in diesem Programm grafisch dargestellt, durch das ein einfaches Anpassen seiner Logikschaltungen möglich ist.

Eine Steuerung des E2000-NET-IO ist möglich durch den Intregrieten Webserver, die PC-Software (E2000-NET-IO Control) oder der Androidsoftware. All diese Können gleichzeitig auf das E2000-NET-IO zugreifen und Funktionen ausführen.

Weitere Informationen gibt es auf der Entwicklerseite: [http://www.elektronik2000.de Elektronik2000.de]

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere in der Datei ENC28J60.H:
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 
Um diesen Code mit einem Atmega1284P verwenden zu können, muss in der main.c in Zeile 38, "TIMSK" durch "TIMSK1" ersetzt werden.
Die Fusebits für den Atmega1284p ohne Bootloader sind:
lfuse=0xFF, hfuse=0xD9, efuse=0xFF

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== Avr ArtNET-Node ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt, dass viel Arbeit und Liebe in diesem Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-Systems, welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== OpenMLP ===
Auf openMCP basierender Port nach [http://avr.myluna.de LunaAVR] (GPL). Umfangreiche Funktionalität und direkte Anpassung an die Sprache. Abgespeckte Version auch auf Atmega32 lauffähig. Die Original-Dokumentation kann zum Großteil hergenommen werden. Einige Zusatzfeatures. Leichte Konfiguration und guter Einstieg für Anfänger und zum Verständnis der Serverfunktionalität.

[http://avr.myluna.de/doku.php?id=de:openmlp Artikelseite]
[http://forum.myluna.de/viewtopic.php?f=8&t=13 Forum]

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

=== AVR-Netino ===
[http://code.google.com/p/avr-netino/ Projekt und Software]

Arduino fürs Net-IO

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://avr.myluna.de/doku.php?id=de:openmlp LunaAVR openMLP ]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

AVR Net-IO Bausatz von Pollin

2013-10-11T00:37:24Z

Kbuchegg: /* AVR-NET-IO */

Hier steht eine Beschreibung des Pollin Bausatzes [http://www.pollin.de/shop/shop.php?cf=detail.php&pg=NQ==&a=MTQ5OTgxOTk= AVR-NET-IO. Best.Nr. 810 058], oder als aufgebautes Fertigmodul, Best.Nr. 810 073.

Einige Features: Ethernet-Platine mit ATmega32 und Netzwerkcontroller ENC28J60. Die Platine verfügt über 8 digitale Ausgänge, 4 digitale und 4 ADC-Eingänge, welche alle über einen Netzwerkanschluss (TCP/IP) abgerufen bzw. geschaltet werden können.

[[Datei:AVR-NET-IO ADD-ON.JPG|thumb|right|400px|AVR-NET-IO (links) mit zusätzlicher SUB-D Anschlussplatine (rechts, nicht im Lieferumfang)und Add-On-Board (oben, mit aufgelötetem RFM12-433-Modul, beides nicht im Lieferumfang). Ebenso ist zusätzlich ein nicht im Lieferumfang enthaltener kleiner Kühlkörper auf einem der Spannungsregler montiert und die Schraubklemmen zur Stromversorgung wurden durch Buchsen ersetzt.]]

== Technische Daten ==

* Betriebsspannung 9 V AC/DC
* Stromaufnahme ca. 190 mA
* 8 digitale Ausgänge (0/5 V) [PC0-PC7 an J3]
* 4 digitale Eingänge (0/5 V) [PA0-PA3 an J3]
* 4 ADC-Eingänge (10 Bit) [PA4-PA7 an Schraubklemmen]
* LCD-Anschluss (HD44780 komp. Controller nötig) [PD2-7,PB0,PB3 an EXT]
* [[ENC28J60]]
* [http://www.atmel.com/dyn/Products/Product_card.asp?part_id=2014 ATmega32] Mikrocontroller

Maße (L×B×H): 108×76×22 mm.

== Hardware ==
=== AVR-NET-IO ===

Die Schaltung des AVR-NET-IO ist recht einfach:
* Ein ATmega32 Mikrocontroller enthält die gesamte Software
* Ein ENC28J60 Ethernet-Controller für das Senden und Empfangen von Ethernet Frames (MAC und PHY Ethernet Layer) ist über [[SPI]] mit dem ATmega32 verbunden
* Ein Ethernet RJ-45 MagJack TRJ 0011 BA NL von [http://www.trxcom.com/ Trxcom] mit eingebautem Übertrager und Anzeige-LEDs am ENC28J60.
* Ein MAX232 für die serielle Schnittstelle
* Zwei Spannungsregler, 5 V und 3,3 V
* "Hühnerfutter"

Fast alle I/O Pins des ATmega32 sind irgendwo auf Anschlüssen herausgeführt. Entweder auf dem SUB-D Stecker, dem EXT oder ISP Wannensteckern oder den blauen Anschlussklemmen. Eine Schutzbeschaltung gibt es nicht.

Die blauen Anschlussklemmen haben eine Nut und eine Feder mit denen man
sie zusammenstecken kann, dadurch ist das Anlöten wesentlich leichter
und sie stehen auch sauber in der Reihe.

=== Erweiterungsplatine ===

Seit Januar 2010 gibt es auch eine Erweiterungsplatine

[http://www.pollin.de/shop/dt/Nzg4OTgxOTk-/Bausaetze/Diverse/Bausatz_Add_on_fuer_AVR_NET_IO.html Add-on für AVR-NET-IO-Board Best.Nr. 810 112]

Diese Platine erweitert das NET-IO um:

* SD-Karten-Slot über SPI
* Display über PCF 8574
* Infrarot-Empfang
* [[RFM12]] Funkmodul (nicht im Lieferumfang enthalten)

Eine Aufstellung bekannter Fehler findet sich weiter unten [[#Bekannte Fehler|Bekannte Fehler - Erweiterungplatine]]

Erste Erfahrungsberichte im Forum http://www.mikrocontroller.net/topic/161354

=== Hardware-Umbauten & -Verbesserungen ===

* Kühlkörper auf dem 7805 - (Vorsicht: Der LM317T ist rückseitig spannungsführend. Den Kühlkörper also keinesfalls an beide Spannungsregler anschließen!)
* MAX232 nach anfänglicher Konfiguration nicht bestücken um Strom zu sparen oder um zwei weitere I/O-Pins zu gewinnen
* 10µF-Elkos für MAX232N (C14-C17) durch 1µF ersetzen. Eine 10µF-Version für den MAX232 gibt es nicht. Die 10µF-Elkos können auch Ursache einer nicht funktionierenden RS232 sein.
** Laut Spezifikation sind auch mehr als 1µF erlaubt. Selbst Atmel verwendet beim STK500 10µF. Dies führt keinesfalls dazu, dass die RS232 nicht mehr funktioniert.
* Die IC-Fassungen aus "Pollins Resterampe" durch Fassungen mit gedrehten Kontakten ersetzen.
* ''Netz'' LED nicht bestücken oder größere Widerstände einlöten um Strom zu sparen (R3)
* Vorwiderstände der Ethernet-LEDs größer machen (z. B. verdoppeln) um Strom zu sparen (R6,R7)
* Linear-Spannungsregler ersetzen
* Kondensator an AREF-Pin des ATmega32 (ATmega32 Datenblatt) (100nF gegen Masse)
* Kondensator an den RESET-Pin des ATmega32 ([http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Atmel Application Note AVR042: AVR Hardware Design Considerations]) Wenn man diese Quelle genauer liest, ist das aber eher unnötig. - Kondensator bei selbstbau-ISP empfehlenswert.
* Umbau auf 3,3 V:
** Ersatz der Spannungsregler durch einen einzigen 3,3 V Regler
** Anpassen (verkleinern) des LED-Vorwiderstands R3 für 3,3 Volt Betrieb
** Reduktion der Taktfrequenz (Austausch von Q2) auf den bei 3,3V erlaubten Bereich des ATmega32 ( ATmega32(L) 3.3V /8.0 Mhz Takt )
** Ersatz des MAX232 durch einen MAX3232
[[Bild:POWER.JPG|thumb|400px|5V Stromversorgung über USB Kabel, ohne 5 V Spannungsregler und Gleichrichterdioden, Vorsicht: kein Verpolungsschutz! ]]
* ATmega32 vom ENC28J60 takten (OSC2)
* Betrieb mit Gleichspannung:
** Dioden D2 und D5 durch Drahtbrücken ersetzen, D1 und D4 nicht bestücken (komplette Entfernung des Brückengleichrichters, beinhaltet Verlust des Verpolungsschutzes)
** Diode D2 bestücken, D5 durch Drahtbrücke ersetzen, D1 und D4 nicht bestücken (Brückengleichrichter durch Verpolungsschutze ersetzen)
*** ??? Ist dies nicht kontraproduktiv? Bei mir wurde durch D2-Bestückung die Eingangsspannung von ca. 5,2 V am LM317T auf ca. 4,6 V gedrückt, so dass am ENC28J60 nur ca. 2,6 V ankamen (außerhalb der lt. Datenblatt "Operating voltage range of 3.14V to 3.45V"). Man müsste also ein geregeltes Netzteil mit ca. 5,5 V anschließen um 5 und 3,3 V zu erzielen. Dann lieber den Verpolungsschutz durch andere Maßnahmen sicherstellen.
** Beim Betrieb von USB beachten, dass USB-Spezifikation keinesfalls 5V garantiert, sondern Spannung bis runter 4.4V erlaubt und dann u.U. durch den LM317 nicht mehr genügend Spannung am ENC anliegt. Das äußert sich so, dass zwar der Atmega einwandfrei funktioniert, die Ethernet-Kommunikation aber nicht oder nur sehr sporadisch.
* Ersatz des ATmega32 durch einen ATmega644 oder ATmega1284p mit mehr FLASH-Speicher.
** Der ATmega644 und auch der ATMega1284p sind nicht mit der Pollin-Firmware kompatibel
* 100nF über alle drei IC Störunterdrückung zusätzlich bestücken

== Inbetriebnahme der Originalsoftware ==
=== Einleitung ===

Die bei Auslieferung (Stand September 2008) in den ATmega32 gebrannte Firmware stellt sich manchmal recht zickig an. Es scheint dann die Netzwerk-Schnittstelle, ggf. auch die serielle Schnittstelle, nicht zu funktionieren. Falls es Probleme geben sollte, sollte man erst einmal ein Firmwareupdate versuchen. Dies geschieht über die serielle Schnittstelle mittels des Programmes NetServer (aktuelle Version 1.03, Februar 2010), die dem Bausatz beiliegt.

Falls die serielle Schnittstelle ebenfalls nicht zugänglich ist, kann mit den im folgenden beschriebenen Schritten die Inbetriebnahme der Software möglich sein. Dazu benötigt man:

* Einen Windows-PC mit Ethernet-Schnittstelle und RS232-Schnittstelle (ein Prolific RS232-USB Konverter funktioniert)
* Entweder
**zwei normale (''straight through'') Ethernet-Kabel und einen Ethernet Switch/Hub, oder
**ein gekreuztes(''cross over'') Ethernet-Kabel
* Einen AVR Programmer (Hardware und Software). Zum Beispiel einen [[AVR Dragon]] oder [[STK500]] mit [[AVR Studio]] oder das [[Pollin ATMEL Evaluations-Board]] und [[avrdude]].
* Die [http://www.pollin.de/shop/ds/MTQ5OTgxOTk-.html Pollin NetServer Software], Version 1.03 (oder neuer)

=== Gelieferten ATmega32 richtig einstellen ===
[[image:fuse_bits_avr_studio.jpg|thumb|right|250px|Einstellungen der Fuse-Bits mittels AVR Studio 4]]
Die Fuses der gelieferten ATmega32s scheinen nicht immer mit den im Handbuch auf Seite 12 als erforderlich angegebenen Fuse-Einstellungen übereinzustimmen.

Dies kann man mittels eines Programmers ändern. LFuse = 0xBF, HFuse = 0xD2. Das genaue Vorgehen hängt dabei vom verwendeten Programmer ab. Bei der Gelegenheit kann man ebenfalls eine Sicherheitskopie des ursprünglichen Flash-Inhalts und des EEPROMs anfertigen. Das EEPROM scheint die MAC-Adresse des Ethernet-Ports zu enthalten.

Entgegen der Spezifikation im Handbuch von Pollin sollten die '''HFuses auf 0xC2''' gesetzt werden, d. h. CKOPT-Fuse programmiert (dies ist in der Software Version 1.03 bereits vollzogen). Das sorgt für einen stabilen Betrieb des AVR-Oszillators im "full rail-to-rail swing"-Mode bei 16 MHz. Atmel garantiert ansonsten nur stabilen Betrieb bis 8 MHz. Siehe ATmega32-Datenblatt, Kapitel 8.4, Crystal Oscillator.
{{Absatz}}

==== Funktionsfähige Konfiguration - AVR-Prog ====

[[Bild:Avrprog.png|thumb|right|250px]]
Benutzer von AVR-Prog können die nachfolgenden Einstellungen für die Lock- und Fuse-Bits verwenden. Hierbei handelt es sich um die ausgelesenen Einstellungen eines funktionsfähigen Controllers. Allerdings sollte, laut Handbuch des AVR-NET-IO-Boards, das Fuse-Bit EESAVE eigentlich gesetzt sein.

Alternativ kann auch per avrdude die Einstellung getroffen werden:
avrdude -c stk500v2 -pm32 -U lfuse:w:0xBF:m
und
avrdude -c stk500v2 -pm32 -U hfuse:w:0xC2:m

Anschließend muß noch der Bootloader und die Firmware aktualisiert werden (siehe Handbuch AVR-NET-IO-Board Seite 12 Punkt 3).

=== PC Konfiguration ===

==== PC normalerweise nicht im 192.168.0.0/24 Subnetz ====

Betreibt man den PC nicht im 192.168.0.0/24 Subnetz, muss er wie folgt umkonfiguriert werden, oder die IP Adresse des Boards wird entsprechend angepasst. ( Siehe Handbuch Seite 14ff. Das ist meist sinnvoller und auch einfacher. )

Den PC vom normalen Netzwerk abstecken[1]. Zur Umkonfiguration dazu bei Windows XP in der Systemsteuerung ''Netzwerkverbindungen'' aufrufen und die lokale ''LAN-Verbindung'' markieren. Dann in der rechten Leiste ''Einstellungen dieser Verbindung ändern'' aufrufen.

Es erscheint der Dialog ''Eigenschaften von <Verbindungsname>''. In der Liste im Dialog zu ''Internetprotokoll (TCP/IP)'' gehen. Ein Doppelklick auf den Eintrag öffnet den ''Eigenschaften von Internetprotokoll (TCP/IP)'' Dialog.

In diesem Dialog ''Folgende IP-Adresse verwenden:'' auswählen und zum Beispiel

IP-Adresse: '''192.168.0.100''' 
Subnetzmaske: '''255.255.255.0''' 
Standardgateway: '''192.168.0.1'''

eingeben.

Anmerkung von bitman:
[1] Dies ist spätestens ab Windows XP nicht mehr notwendig, wenn das Netz 192.168.0.0/24 noch frei ist. Dann kann man einfach den Client ''zusätzlich'' in diesem Netzwerk zusätzlich einbinden über Einstellungen/Netzwerkverbindungen/Lanverbindung/Eigenschaften/TCP-IP/Eigenschaften/Erweitert/IP-Adresse hinzufügen. Es werden dann eben mehrere IP-Adressen an den NIC gebunden.

Alle geöffneten Dialoge nacheinander mit OK schließen.

Alternativ bietet sich das Umprogrammieren des Boards über die serielle Schnittstelle an. Die Werte für IP-Adresse, Netzmaske und Standard-Gateway werden mit den dokumentierten SETxx-Befehlen geändert, das Board neu gestartet und ans vorhandene Netzwerk gesteckt.

Im EEPROM sind folgende Werte vorprogrammiert: 
3EE - 3F3 MAC-ADRESSE 
3F4 - 3F7 GATEWAY 
3F8 - 3FB NETMASK 
3FC - 3FF IP-ADRESSE 

==== PC bereits im 192.168.0.0/24 Subnetz ====

In diesem Fall muss man prüfen, ob die IP-Adresse 192.168.0.90 bereits im Subnetz verwendet wird. Ist dies der Fall, muss das verwendete Gerät mit dieser IP vorübergehend aus dem Subnetz entfernt werden. Es sei denn, dabei handelt es sich um den PC. In diesem Fall muss er wie zuvor umkonfiguriert werden. Ansonsten kann der unverändert im Netz verbleiben.

Dem AVR-NET-IO gibt man eine neue, zuvor unbenutzte Adresse (siehe unten). Dann kann das abgekoppelte Gerät wieder angeschlossen werden, beziehungsweise der PC zurückkonfiguriert werden.

=== AVR-NET-IO anschließen ===

Musste man den PC umkonfigurieren, so werden jetzt nur der PC und der AVR-NET-IO über Ethernet miteinander verbunden. Je nach Ethernet-Kabel benötigt man dazu einen Switch/Hub oder nicht.

Musste man den PC nicht umkonfigurieren, so kann man den AVR-NET-IO wie einen normalen Rechner an das vorhandenen Netz anschließen.

Zusätzlich schließt man die serielle Schnittstelle des AVR-NET-IO an den PC an.

=== Firmware 1.03 einspielen ===

Laut Handbuch sollte der AVR-NET-IO jetzt über Ethernet funktionieren. Ebenso sollte er über die serielle Schnittstelle und ein Terminalprogramm konfigurierbar sein. Beides ist offensichtlich im Auslieferungszustand selten der Fall.

Auch wenn sich Pollins NetServer Software nicht mit dem AVR-NET-IO verbinden lässt, so ist sie jedoch in der Lage eine neue Firmware 1.03 einzuspielen. Das Vorgehen ist im Handbuch auf Seite 12 beschrieben. NetServer präsentiert dabei ein paar einfache Anweisungen denen man folgen sollte.

Wenn sich nach dem scheinbar erfolgreichem Einspielen der Firmware, später nichts tut, so sollte die Firmware mit gesetztem "FailSafe" in der mitgelieferten NetServer-Software nochmals Eingespielt werden.

=== Abschluss ===

Jetzt sollte sich die NetServer Software mit dem AVR-NET-IO über Ethernet verbinden lassen. Dies macht es wiederum möglich, den AVR-NET-IO mit einer anderen IP-Adresse zu versehen. Will man den AVR-NET-IO in einem anderen Subnetz betreiben kann man dies jetzt einstellen.

Nachdem man die IP-Adresse neu eingestellt hat, muss man den PC zurückkonfigurieren und kann dann sowohl den AVR-NET-IO und den PC zusammen betreiben.

== Bekannte Fehler ==
=== AVR-NET-IO ===

Siehe auch [[#Hardware-Umbauten_.26_-Verbesserungen|Hardware-Umbauten und Verbesserungen]] 
Käufer berichten von fehlenden Bauteilen im Bausatz (Wannenstecker, Widerstände, Kondensatoren, Induktivitäten). Für Reklamationen: [https://www.pollin.de/shop/kontakt_service/reklamation.html]

* Die Stückliste auf Seite 4 in den Anleitung mit den Versionsangaben
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
:ist falsch. Pollin legt dem Bausatz irgendwann ab September 2008 einen gedruckten Korrekturzettel bei. Die Online-Version der Anleitung ist korrigiert.
* Im Schaltplan auf Seite 7 in den Anleitungen mit den Versionen
** ''Stand 20.08.2008, kloiber, #1100, wpe'' (gedruckt im Bausatz)
** ''Stand 20.08.2008, cd, #all, wpe'' (auf der CD)
** ''Stand 03.09.2008, online, #all, wpe'' (Online)
:ist eine 25-polige SUB-D Buchse gezeichnet. Geliefert wird und in der Stückliste verzeichnet ist ein Stecker.

* Die September 2008 ausgelieferte Firmware im ATmega32 funktioniert bei vielen nicht und muss erst upgedatet werden (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Im Flash der gelieferten AVR ist anders als beschrieben nur der Bootloader enthalten, die eigentliche Firmware muss erst mit Hilfe der Updatefunktion geladen werden. Wenn zusätzlich auch die Fuses falsch gebrannt sind, dann funktioniert das Update nicht, auch wenn das PC Programm was anderes behauptet.

* Die Fuse-Einstellungen des ausgelieferten ATmega32 entspricht nicht der Anleitung (siehe [[#Inbetriebnahme der Originalsoftware|Inbetriebnahme der Originalsoftware]])

* Bausatz, gekauft am 27.10.08, Anleitungsversion 19.09.08, ohne Probleme oder erkennbare Fehler zusammengebaut und in Betrieb genommen.

* Bausatz gekauft 29.09.2008, Pinbelegung des 25 poligen D-Sub "Anschlusses" stimmt nicht mit der Anleitung überein. Der Aufdruck auf der Platine ist falsch. Pin1 <-> Pin13, Pin2 <-> Pin12 usw. Setzt man den D-Sub Stecker ein, so sind dessen Pinnummern korrekt. Bei einem Bausatz gekauft 05/2013 ist dies ebenfalls noch der Fall.

* 3 Bausätze Anf. Oktober 2008 gekauft, bei einem waren 2 LM317 dabei, dafür fehlte der 7805 - aus der Bastelkiste ersetzt. Alle haben jedoch auf Anhieb funktioniert

* Bausatz gekauft Ende Januar 2009. Die Lock-Bits (u.a. für PonyProg2000) werden falsch beschrieben. Die in Klammern aufgeführten Werte stimmen bei einem Bit nicht. Die Texte "Programmiert/Unprogrammiert" hingegen schon. Bei den Bauteilen gab es 4 Kondensatoren mit der Aufschrift "220", ich habe diese durch welche mit 22p ersetzt, da ich nicht sicher war ob wirklich 22p geliefert wurden. Dafür wurden statt einem zwei 7805 und statt einem mindestens vier LM317 mitgeliefert.

* Bausatz geliefert 22.4.2009. Alles vollständig, zusammengebaut, läuft. Software-Version 1.03. Für den oben schon genannten Steckverbinder wurde eine Buchse geliefert. Allerdings stimmen die PIN-Nummern im Schaltplan nicht mit den PIN-Nummern auf der Buchse überein (sie sind gespiegelt), daher liefen die Test-LEDs zunächst nicht.

* Bausatz geliefert 11.7.2009. Spannungsregler LM317T fehlt, grüne statt roter LED. Ein Kondensator 22pF zu viel. LM317T wurde auf Anfrage kostenlos nachgeliefert (27.7.). Inbetriebnahme problemlos.

* Bausatz geliefert 24.7.2009. Ein Quarz 16MHz zu viel, ebenfalls grüne statt rote LED.

* Bausatz geliefert 20.08.2009. Ein Kondensator 22pF zuviel und grüne statt rote LED.

* Bausatz Juli '09 gekauft, grüne statt rote LED

* Bausatz 25.09.09 geliefert, grüne Betriebs-LED, ein ELKO zuviel, Fehler 1µF am MAX232 statt 100nF behoben, richtiger C wird mitgeliefert, Aufbau komplett nach Pollin Anleitung durchgeführt, auf Anhieb fehlerfrei!

* Bausatz 17.10.09 geliefert, grüne Betriebs-LED, zwei 100nF Kondensatoren zu wenig. Aufbau und Inbetriebnahme problemlos.

* Bausatz 21.10.09 gekauft, grüne Betriebs-LED. Aufbau problemlos, RS232 läuft nicht. LAN läuft

* Bausatz Nov. 09 gekauft, grüne LED, alles o.k.

* Bausatz Nov. 09 gekauft, grüne LED, ENC28J60, MAX232 und ATmega32 fehlen, Nachlieferung nach einer Woche

* Bausatz Nov. 09 gekauft,Bauteile komplett.Verbindungsaufbau Seriell klappt erst nach mehreren Versuchen.Problem gelöst:Spannung an MAX und Mega zu niedrig

* Bausatz Dez. 09 gekauft, grüne LED, 100µF Kondensator fehlt, alles o.k.

* Bausatz August 09 gekauft, alle teile da nach Einstellen der fusebits lief alles perfekt

* Bausatz Okt. 09 gekauft, ein 100nF Kondensator und 25MHz Quarz fehlten ... hab beim lokalen Elektronikhändler keinen 25Mhz Grundton Quarz sondern nur im 3. Oberton bekommen aber mit R2.2k parallel zum Quarz schwingt er in der Schaltung schön bei 25Mhz. Mit 1µF am MAX232 funktioniert jetzt auch die RS232.

* 2x Bausatz Feb. 10 gekauft, bei beiden fehlten 7805, L1+L2 je 100µH sowie 4x falscher Wert Kondensator an Max232 vorhanden. Fehlende Bauteile nachgelötet und Funktion getestet. Hat alles einwandfrei funktioniert!!!

* Bausatz März. 10 gekauft, RS232 Printbuchse fehlt, dafür 1x 10pol Wannenstecker zuviel. Grüne LED statt Rot. Funktioniert ansonsten einwandfrei.

* Bausatz Jan. 10 gekauft, gelbe LED statt rot, C14...C17: 10µF, weder seriell noch via Ethernet Konnektivität. Nach Austausch von C14-C17 gegen 1µF, wenigstens serielle Kontaktaufnahme möglich, kein Ethernet auch nach Flash von 1.03 mit NetServer.

* Bausatz Feb. 10 gekauft, Spannungsregler LM317T fehlte

* Bausatz März 10 gekauft, gelbe statt rote LED geliefert, aber Aufbau und inbetriebnahme lt. Handbuch ohne Probleme

* Bausatz März 10 gekauft und gelbe statt rote LED geliefert, funzt wunderbar gemäß Anleitung

* Fertig gelötete Platine gekauft. µC war falsch im Sockel.

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - Funktion erst nach Ersetzung des ADM durch nen MAX

* Bausatz April 10 gekauft und gelbe statt rote LED geliefert, ADM232LJN statt MAX232 - funktionierte sofort auch mit dem ADM232LJN.

* Bausatz April 10 gekauft wurde mit grüner statt roter LED Ausgeliefert

* Bausatz Juni 10 gekauft: wurde mit grüner statt roter Netz-LED ausgeliefert, 2x 22pF Kerko zuviel

* Bausatz August 10 gekauft: komplett und sofort funktioniert

* Bausatz Juli 10 gekauft: 2 Quarze mit 16 MHz geliefert, statt 1x 16MHz und 1x25MHz.

* Bausatz September 10 gekauft: hat sofort funktioniert. 1x 3,3k und 1x 10k Widerstand zuviel. Statt 100nF Kondensatoren wurden 1µF geliefert -> Platzprobleme auf der Platine durch grössere Bauform. LED grün.

* Bausatz Oktober 6 gekauft: alles funktioniert. LED grün statt rot.

* Fertigmodul Oktober 10 gekauft: Auf Anhieb alles funktioniert!

* Bausatz Oktober 10 gekauft: komplett und sofort funktioniert

* Bausatz November 10 gekauft: komplett und sofort funktioniert (sogar mit der neusten Pollin Firmware 1.03 schon drauf) LED grün statt rot.

* Bausatz November 10 gekauft. Nach Bezug neuer Feinst-Lötspitzen konnte ich ihn dann auch zusammenlöten. Es hat sofort alles funktioniert, obwohl ich nur 12V bzw. 9V Gleichspannung zur Verfügung hatte, und nicht sicher war, wieviel die Komponenten wirklich benötigen. Der Regler wird auch bei 9V Gleichspannungsversorgung noch sehr warm. Da muss auf jeden Fall ein Kühlkörper dran! Ich habe auch eine grüne LED bekommen, ist mir aber wurscht :-)

* Bausatz Dezember 10 gekauft: komplett und funktionierte sofort. Firmware 1.03, grüne LED (Ein Quarz und ein IC-Sockel zu viel)

* Bausatz Januar 2011 gekauft: nur genau die richtige Anzahl Teile dabei, Firmware 1.03, grüne LED, ging auf Anhieb

* 2x Bausatz Januar 2011 gekauft: beide grüne LED, und 1x doppelter Satz Jumper/Stiftleiste, 22PF und Anschlussklemmen. Rest vollständig und beide haben sofort nach zusammenbau funktioniert.

* Februar 2011: AVR-NET-IO: die Diode D5 fehlt, 10 µF gegen 1 µF für MAX232 getauscht, Flash im ATmega32 war programmiert, passende IP-Adr über serielle Schnittstelle eingestellt; ADD-ON: für R1 war 22Ω statt 0,2Ω beigelegt, durch richtigen ersetzt, Beschreibung der LED Bestückung mangelhaft / oe1smc

* Februar 2011: AVR-NET-IO: 1 Diode zuviel, 2 Spulen fehlen, LED grün. Die fehlenden Spulen wurden durch welche aus der Bastelkiste ersetzt - funktioniert. Der 7805 bekam einen kleinen Kühlkörper spendiert.

* Februar 2011: AVR-NET-IO: 2x 10k Widerstände fehlen. Dafür eine Diode zu viel.

* Ende Februar 2011: Zwei Bausaetze an jeweils zwei Adressen, alles in Ordnung.

* Ende März 2011: 2x 25 Mhz Quarz statt 1x16 u. 1x25 Mhz. LED fehlt. Bausatz funktioniert nach Tausch des Quarz den mir mein Freund oe9rsv aus seinem Fundus spendiert hat. Danke auch für die Hilfe beim Fehler suchen.

* Mitte 2010 gekauft: 1x 100nF fehlt

* Mitte Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, Pollin wollte, dass ich das ganze Paket zurückschicke für einen Austausch. Ein 51Ω zu viel. 16Mhz im Handel und 25Mhz vom alten Mobo ausgelötet. Läuft wunderbar.

* Anfang Juni 2011: Beide Quarze fehlen und beide Spannungsregler fehlen, nach kurzer Mail an Pollin (leider ohne Antwort) wurden diese nach ca. 1 Woche in einem Brief nachgeliefert.

* August 2011: alles 1a...

* August 2011: Platine fehlte -> in Nachlieferung

* 30 August 2011: alles 1a...

* 06 Sep. 2011: alles 1a...

* August 2011: 6 Stück bestellt, bei einem haben die 100nF Kondensatoren gefehlt, bei einem zwei LM317 statt 7805 und LM317. Angerufen, 3 Tage später Nachlieferung erhalten.

* Nov. 2011: '''Net_IO''' vollständig. Einspielen der Firmware 1.03 war erforderlich. Bei '''Add-On''' immer noch falscher Q1 BC548 (NPN) in Stückliste und Lieferung. BC327-40 oder BC328-40 (PNP) nachgefordert. R11 und R24 mitgeliefert, entsprechend Beschreibung V1.1 von Pollin's Download. Beiliegende Beschreibung war älter, ohne diese Widerstände.

* Ende Nov.2011, alle Teile dabei, Firmware war drauf, sofort funktioniert.

* Anfang Dez.2011, komplett bestückte Platine gekauft. Auf 7805 Kühlkörper gebaut, da er nach 1 Minute schon ausgestiegen ist (LED hat das Pumpen angefangen). Firmware 1.03 musste noch aufgespielt werden danach funktioniert alles einwandfrei. In Betrieb mit 10V DC

* Ende Dez.2011 2xNET-IO und 2xADD bestellt, 4 verschieden volle Kisten bekommen... WSL16 ist mit Verriegelung, geht nicht aufs Board, Jumper fehlen, Spannungsregler doppelt, Poti Löcher zu klein, lsb3 fehlt, SD-Slot hab ich jetzt 3, 100nF hab ich jetzt 4 übrig ... also immer noch lustig. HW-Stand immer noch 1.0 ( gab es überhaupt eine 1.1?)

* Mitte Jan. 2012, 10pol. beide Wannenstecker nicht dabei, Firmware war drauf, sofort funktioniert. 1 LED zuviel. Unproblematische Nachlieferung bei Reklamation (wegen der beiden Wannenstecker kam ein PAKET!).

* Ende Feb. 2012, Um die PHP-Scripte über öffentlichen Webserver zu betreiben muss mit SETGW die Gateway-Adresse des lokalen Routers eingetragen werden. Bei der NAT im Router sollte z.B. Port 8080 auf den internen Port 50290 umgeleitet werden, da manche Provider diesen Port für die Socket-Kommunikation nicht zulassen.

* Juli 2012, Bausatz vollständig, Nach Aufbau sofort den 7805 mit einem kleinen Kühlkörper versehen, da er sonst thermisch überlastet wird! hat weder auf LAN noch RS232 reagiert, musste erst Update einspielen (Download Pollin), danach funktionierte alles einwandfrei!

* Januar 2013, Bausatz vollständig, 7805 mit Kühlkörper versehen, nach Aufbau ohne Probleme funktioniert

* Februar 2013, Bausatz komplett, Aufbau ohne Probleme, 7805 nur leicht warm, LAN funktioniert, RS232 noch ohne Funktion.

* Oktober 2013, Bausatz komplett laut Stückliste, problemloser Aufbau, 7805 leicht warm am 10V DC. RS232 und LAN funktionierten auf Anhieb.

=== Erweiterungsplatine ===

Die nachfolgend genannten Änderungen sind in der Bauanleitung V1.1 mit Stand 07.12.2011 (Wichtig! Es gibt mehr als eine V1.1 ...) bereits berücksichtigt, R3 wird allerdings mit 3,6kΩ angegeben.

Um bei einem Neuaufbau parallele Widerstände zu vermeiden, sollten folgende Änderungen auf dem Addon-Board gemacht werden:
*R2 1,5kΩ ersetzen mit 2kΩ
*R3 1,8K ersetzen mit 3,3kΩ
*R19 470kΩ ersetzen zu 470Ω
*Q1 BC548 ersetzen durch BC327 oder BC328 (Hauptsache PNP! und mehr als 100mA)

'''ACHTUNG''' beim Anschluß eines LC-Displays an J5 (über I2C, PCF 8574): Vcc/5V liegt an Pin 1, GND an Pin 2 von J5. Es gibt etliche Displays mit abweichender Belegung Pin 1 GND und Pin 2 Vcc!

Auch beim Add-On gibt es fehlende oder falsche Bauteile im Bausatz und Fehler im Schaltplan und auf der Platine:

*Stand Feb. 2011: R2 wird mit 2,2kΩ und R3 wird mit 3,6kΩ ausgeliefert. Somit werden die 3,3 V richtig erzeugt. R19 hat 470Ω. Der ISP-Anschluß ist nicht vollständig durchgeschleift, es besteht keine Verbindung der RESET-Leitung zwischen ISP und ISP1 (Abhilfe: Drahtbrücke einlöten, [http://www.mikrocontroller.net/topic/161354#1600385 Quelle]).

*Stand Nov. 2011: bei mir ist die RESET-Leitung korrekt zw. ISP und ISP1 verbunden. Es gibt jetzt auch einen R24 (470Ohm) und R11 (1KOhm), der in der bei mir mitgelieferten Bauanleitung fehlt, in der zum Download (V1.1) angebotenen aber drin steht. Es wird immer noch der falsche Q1 BC548C (NPN) mitgeliefert. Das Schaltsymbol für einen PNP ist richtig im Schaltplan gezeichnet.

*Stand Dez. 2011: R24 (470Ω) kann mit 0Ω ersetzt und R11 (1kΩ) völlig weggelassen werden. Diese Widerstände bilden einen (eigentlich überflüssigen) Spannungsteiler in der MISO Leitung. Der Spannungsteiler hat allerdings auch eine Schutzfunktion, falls weitere Slaves am SPI-Bus hängen, die 5V-Pegel nutzen, z. B. ISP-Programmierer. (siehe [http://son.ffdf-clan.de/include.php?path=forumsthread&threadid=1167&postid=9203 1284p: Board, ich oder beide verwirrt?])

*Sept'12: Bausatz mit Stecker anstelle einer Buchse ausgeliefert, 5mm anstelle von 3mm LED's dafür aber 3 Poti zuviel.

*Sept'12: Ebenfalls Bausatz mit Sub-D-Stecker statt Buchse ausgeliefert, 5mm anstelle von 3mm LED's und 3 Potis zuviel.

*Stand März 2013: Die Belegung der 25 pol. Sub-D-Buchse im Schaltplan der Anleitung V1.1 (und früher) ist falsch dargestellt. SCL und SDA des I2C-Busses liegen wie beim AVR-NET-IO Board auf Pin 2 bzw. 3 und nicht auf Pin 11 bzw. 12 der Buchse. Ein 1:1 verdrahtetes Kabel funktioniert.

== Andere Software für den Client-PC ==
=== NetIOLib ===

In C# geschriebene Bibliothek zur Ansteuerung der Platine im Orginalzustand. Inkl. Beispielsoftware und Quellcode (GNU GPL)

Links gehen nicht:
DLL: [http://www.tware.org/downloads/NetIOLib_dll.zip Download-Link]
Source: [http://www.tware.org/downloads/NetIOLib_src.zip Download-Link]

=== E2000-NET-IO-Multi-Control ===
Mti dem E2000-NET-IO-Multi-Control ist es möglich, die vom dem E2000-NET-IO-Designer erstellten Projekte zu öffnen und die AVR-NET-IO's zu steuern.

Die Anwendung liegt dem [http://www.mikrocontroller.net/articles/AVR_Net-IO_Bausatz_von_Pollin#E2000-NET-IO-Designer_.28Windows.5BXP.2F7.5D_.2F_Android.29 E2000-NET-IO-Designer] bei.

=== ControlIO ===
Einfache Bibliothek zur Ansteuerung mit Originalfirmware.
http://www.mikrocontroller.net/topic/149695

=== JAVA Lib ===
Einfache Java-Bibliothek zur Ansteuerung mit Originalfirmware.
http://son.ffdf-clan.de/?path=forumsthread&threadid=611

=== PHP ===
PHP Klasse zur Ansteuerung mit der Originalfirmware. (Opensource Lizenz)
http://blog.coldtobi.de/1_coldtobis_blog/archive/298_pollin_net-io_php_library.html

PHP Funktionen zum Ansteuern der Originalfirmware. (Free for All Lizenz)
http://defcon-cc.dyndns.org/wiki/index.php/Pollin_AVR-NetIO_PHP_Wrapper

== Clients für Smartphones ==

=== AVR NET IO Control (Windows Phone 7.5,7.8,8.0) ===

Freie App zur steuerung des AVR NET IO.

'''App im Market: [http://www.windowsphone.com/de-de/store/app/avr-net-io-controll/030d107f-9a27-4a62-ac8f-cb74e79c0500 AVR NET IO Control]'''
=== App NetIO (Windows Mobile 6.5) ===
Frei verfügbare App für Windows Mobile zur Ansteuerung mit der Orginalsoftware. Das HTC HD2 wird damit zur Fernsteuerung für das AVR Net-IO Board.
http://www.heesch.net/netio.aspx

=== NET-IO Control (Android) ===
Eine Application für das Android Betriebssystem zur Steuerung des AVR Net-IO Boards. Es ist möglich, alle Ausgänge zu steuern und alle Eingänge anzuzeigen. Die Analogen Eingänge können mit einem Berechnungsfaktor versehen werden. ''Geplant ist noch ein Offsetwert.'' Außerdem kann jedem analogen Wert eine Einheit zugeordnet werden. Die Ausgänge können in der neusten Version in einen Tastermodus gesetzt werden.

[[Datei:NET-IO-Control.png|200px]] [[Datei:NET-IO-Control2.png|200px]] [[Datei:NET-IO-Control3.png|200px]]

'''Trial-Version: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControlTRAIL Google-Play]'''

(In dieser Probe Version können nur 1 Output und 2 Inputs gesteuert werden)

'''Vollversion: [https://play.google.com/store/apps/details?id=de.android.AVR.NETIOControl Google-Play]'''

(Kostet im Google-Play 3,00 €)

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== E2000-NET-IO-Designer (Windows[XP/7] / Android) ===
[[Datei:E2000-NET-IO-Designer.png|400px|right]]
Mit dem E2000-NET-IO-Designer ist es möglich, eine grafische Oberfläche für die NET-IOs von Pollin zu erstellen. Dafür werden Knöpfe, Texte und Anzeigebilder zur Verfügung gestellt. Jedes dieser Element kann "Aufgaben" übernehmen um die NET-IOs zu steuern oder einen Status des NET-IO anzuzeigen. Weitere Icons können von dem Benutzer selbst in den entsprechenden Ordner gelegt werden und in die Oberfläche eingebunden werden. Es können mehrere Seiten designt werden die durch einen selbst positionierten Knopf erreichbar sind. Die Android Application arbeitet somit im Fullscreen-Modus. Des weiteren ist es möglich, mehrere NET-IO's in einem Projekt zu benutzen. Nach dem erstellen der grafischen Oberfläche mit dem E2000-NET-IO-Designer, kann mit der Android APP das Projekt einfach gedownloaded werden. Dafür baut die APP eine Verbindung zum E2000-NET-IO-Designer auf und läd alle benötigten Dateien herunter (Achtung: Firewall-Einstellungen beachten). Die designten Oberflächen können außerdem noch mit der E2000-NET-IO-Multi-Control.exe auf dem Computer ausgeführt werden. Dadurch ist es Möglich, seine NET-IOs vom PC aus zu steuern über eine selbst designte Oberfläche.

Zum Ausführen des E2000-NET-IO-Designer muss .NET Framework 4.0 installiert sein und es muss eine Internetverbindung exisitieren.

'''Features:'''<ul>
<li>Grafische Oberfläche am PC erstellen</li>
<li>Verwendung von eigenen Button- und Hintergrundbildern</li>
<li>Designbare Anzeige von Digital- und Analogwerten</li>
<li>Steuern von mehreren AVR-NET-IO Boards</li>
<li>Unterstützung der E2000-NET-IO Firmware (mehere Boards gleichzeitig)</li>
<li>Designte Steuerungen können auf dem PC oder dem Handy ausgeführt werden (Android)</li>
<li>Schnelle Verbindung</li>
<li>Einfache übertragung auf das Handy durch Projekt Download</li>
</ul>

[http://www.elektronik2000.de/downloads.php?id=44 Download E2000-NET-IO-Designer]

[http://www.elektronik2000.de/hilfe/E2000Netdesigneruebersicht.html Online Hilfe]

Weitere Informationen sind auf der Entwickler-Seite zu finden: [http://elektronik2000.de/ Elektronik2000.de]

=== NetIO ( iPhone & Android ) ===
<div style="float: left; margin-right: 20px">[[Datei:Netio_logo.png|70px]]</div>

Schöne universelle Fernbedienung für das Board (iOS / Android). Konfigurierbar über einen Browserbasierten Editor. 
Unterstützt TCP socket Verbindungen, kann http request absetzen und kann auch Webseiten einbinden (z.B. IP-Kameras). Kann mehrere
Boards gleichzeitig steuern! Einfach super schnell ins Projekt eingebaut... Es gibt Buttons (die auch als Taster konfiguriert werden können), Slider, Switches und einfache Labels. Dinge können geschaltet oder Daten ausgelesen und mit regex dargstellt werden.

<div style='float: right'>
[[Datei:Netio_TV.png|190px]]
[[Datei:Netio_iphone5.png|190px]]
[[Datei:NetIO_appflow.jpg|190px]]
</div>

 
AppStore Link: http://itunes.apple.com/app/netio/id464924297?mt=8 
Google Play Link: https://play.google.com/store/apps/details?id=com.luvago.netio 
Die gleiche Konfiguration kann auch mit einem [https://github.com/davideickhoff/NetIO-OSX-Dashboard-Widget OSX Widget] benutzt werden. 
Webseite: http://netio.davideickhoff.de

Hinweis: Man findet es unter "NetIO" im Store, im Icon selbst und in iTunes wird es als "Controller" angezeigt. 
Die eigene Konfiguration kann man mit dem [http://netio.davideickhoff.de/editor Online Editor] vorher am PC erstellen.
Eine fertige [http://netio.davideickhoff.de/editor/?config=pollin AVR-NET-IO Konfiguration] gibt es als funktionierendes Beispiel schon als Preset.

 
<div style='clear: both'></div>

=== AVR Net IO (iPhone) ===
[[Datei:AVRNetIO-Screenshot1.png|160px|rechts]]
Update 15.12.2011: Die Neue Version 1.3 ist seit gestern im AppStore. Fehlerkorrekturen und ein robusteres Handling machen die App nun zur universellen AVR-Net-IO-Steuerung.

Mit der [http://itunes.apple.com/de/app/avr-net-io/id460991760?mt=8 iPhone App AVR-Net-IO] kann das Board ferngesteuert werden. Die Fernsteuerung umfasst in der Version 1.1 folgende Funktionen: <ul>
<li>ADC-Werte zyklisch auslesen und darstellen</li>
<li>Digital-Inputs zyklisch darstellen</li>
<li>Digital-Outputs können über Buttons geschaltet werden. Die Werte der Digital-Outputs werden zuerst ausgelesen und zeigen den zuletzt gesetzten Wert an.</li>
<li>Terminal-Modus: Hier können beliebige AVR-Net-IO-Befehle eingegeben werden. Das Ergebnis wird 1:1 angezeigt, wie es vom Board kommt. Hilfreich für Tests bei Eigenentwicklungen und Konfigurationen.</li>
</ul>
 
Mehr Infos gibt's dazu direkt von den Entwicklern auf [http://www.facebook.com/pages/AVR-Net-IO/187799687958255?ref=nf AVR-net-IO Facebook-Page] oder direkt auf deren Homepage [http://www.ondics.de/apps/1001/ Homepage].
 
Hinweis: MIt der aktuellen Version 1.1 gibt es noch bei manchen Boards Probleme beim auslesen und anzeigen der ADC- und Digital-Werte. Das Terminal funzt problemlos. Die Entwickler kümmern sich gerade drum und haben einen baldigen Update versprochen.
 

== Andere Software statt der Originalsoftware von Pollin ==

Die Umrüstung auf einen Webserver durch Austausch der Software (und ev. des ATmega32) bietet sich an. Kleiner Hinweis dabei: wenn zum Flashen ein ISP-Adapter verwendet wird, diesen unbedingt vor dem Start der neuen Software abziehen! Der ISP arbeitet nämlich über dieselbe SPI-Schnittstelle über die auch der ENC28J60 angesteuert wird. Ein eventuell noch angeschlossener, wenn auch passiver ISP-Adapter stört diese Kommunikation, d.h. das Programm an sich scheint zu laufen, aber die Ethernet-Schnittstelle funktioniert nicht.

=== E2000 - Logik ===

[[Datei:E2000-Logik-Bedienoberflaeche.jpg|500px|rechts]]

Anwenderfreundliche Logik-Software von Elektronik2000.de zur Steuerung des AVR-NET-IO. Der ATMEGA32 wird durch einen ATMEGA644 ersetzt und mit der E2000-Firmware beschrieben. Nun ist es möglich in der E2000-Logik Software eine Logikschaltung zu erstellen und diese auf das NET-IO-Board zu übertragen. Dort wird diese Schaltung simuliert. Dies funktioniert komplett ohne einen Computer.

Durch ein Erweiterungsboard von Elektronik2000.de ist es auch möglich, das Board ohne Internet laufen zu lassen eine RTC (RealTimeClock) übernimmt dabei die Uhrzeitgesteuerten Funktionen. Auf dieser Erweiterung ist auch ein EEPROM integriert, um Firmware-Updates über Netzwerk einzuspielen (in Zukunft). Diese Erweiterung bietet außerdem die Anbindung an das E2000-Bus-System, durch das es möglich ist das AVR-NET-IO-Board durch weitere Ein- und Ausgänge zu erweitern.

Das Designen von Schaltaufgaben wird in diesem Programm grafisch dargestellt, durch das ein einfaches Anpassen seiner Logikschaltungen möglich ist.

Eine Steuerung des E2000-NET-IO ist möglich durch den Intregrieten Webserver, die PC-Software (E2000-NET-IO Control) oder der Androidsoftware. All diese Können gleichzeitig auf das E2000-NET-IO zugreifen und Funktionen ausführen.

Weitere Informationen gibt es auf der Entwicklerseite: [http://www.elektronik2000.de Elektronik2000.de]

=== Bascom Version von Hütti ===

(Quelle: http://bascom-forum.de/index.php/topic,1781.45.html )
dort am Ende der Seite.

=== Ben's Bascom Quellcode ===

(Quelle: http://members.home.nl/bzijlstra/software/examples/enc28j60.htm )

Muss aber für Bascom 1.11.9.3 angepasst werden, siehe Code von Hütti !

=== U. Radigs Webserver ===

Angepasster Sourcecode von U.Radig: http://www.mikrocontroller.net/attachment/40027/Webserver_MEGA32.hex
oder selbst anpassen:
Ändere in der Datei ENC28J60.H:
#define ENC28J60_PIN_CS 4
(Quelle: http://www.mikrocontroller.net/topic/109988#988386)

Temporären Dateien (*.d, *,lst,*.o) vorher im Verzeichnis löschen ''make clean'', damit neu compiliert wird.

IP: 192.168.0.99 
User: admin 
Pass: uli1 

Den orginal SourceCode gibt's übrigens hier:http://www.ulrichradig.de/home/index.php/avr/eth_m32_ex

Bei den Fuses BOOTRST ausschalten, da die Software keinen Bootloader enthält.

IP: 192.168.1.90 
User: admin 
Pass: tim 
Test: http://beitz-online.dyndns.org 
Test: http://pieper-online.dyndns.org 

Weiterentwicklung des Radig-Codes von RoBue: 
- 1-Wire-Unterstützung (Anschlus an PORTA7) 
- PORTA0-3 digitaler Eingang (ein/aus) 
- PORTA4-6 analoger Eingang (0 - 1023) 
- LCD an PORTC 
- Schalten in Abhängigkeit von Temperatur und analogem Wert 
- (Teilweise) Administration über Weboberfläche 
- Erweiterung des cmd-Befehlsatzes für telnet/rs232 
Gedacht ist der Einsatz des AVR-NET-IO-Bausatzes für Heizungs- oder Haussteuerung) 

Test: http://avrboard.eluhost.de/ 

(Quelle: 
http://www.mikrocontroller.net/attachment/43307/AVR-NET-IO_RoBue_V1.3.zip 
http://www.mikrocontroller.net/attachment/44569/AVR-NET-IO_RoBue_V1.4.zip 
http://www.mikrocontroller.net/attachment/46720/AVR-NET-IO_RoBue_1.5-final_hoffentlich_.zip)

Bei der Ver 1.5 sind die Ports PD2+3 fürs 4bit LCD (Ext.) vertauscht ! Gruß B.P

=== Simon Ks Webserver (uip-Stack) ===
Angepasster Sourcecode von Simon K: http://www.mikrocontroller.net/attachment/39939/uWebSrv.zip
IP: 192.168.0.93:8080 
Um diesen Code mit einem Atmega1284P verwenden zu können, muss in der main.c in Zeile 38, "TIMSK" durch "TIMSK1" ersetzt werden.
Die Fusebits für den Atmega1284p ohne Bootloader sind:
lfuse=0xFF, hfuse=0xD9, efuse=0xFF

=== Ethersex Server ===

http://www.ethersex.de - Einfach für atmega32 compilieren und funktioniert.

=== Etherrape Server ===

http://www.lochraster.org/etherrape/

ist in jedem Fall hier auch zu erwähnen zumal es sich beim etherrape um das Ursprungsprojekt von ethersex handelt.
Es scheint aber bei der Weiterentwicklung wenig zu passieren.
Ausführliche Dokumentation findet sich unter http://wiki.lochraster.org/wiki/Etherrape

=== Mini SRCP Server (kommerziell, Closed-Source)===

Damit wird die Platine zu einer Modellbahnsteuerung, die
über das Netzwerkprotokoll SRCP mit verschiedenen Programmen
gesteuert werden kann.

[http://www.7soft.de/de/mini_srcp_server/index.html Infoseite] zur Hardware
und das zugrundeliegende [http://www.der-moba.de/index.php/Digitalprojekt Digitalprojekt].

=== Avr ArtNET-Node ===

Hiermit kann die Platine zu einem Art-Net Node werden, mit dem sich ein DMX-Universe über Ethernet übertragen lässt. Basiert auf den Quellen von Ulrich Radig.

Dokumentation: [http://www.dmxcontrol.de/wiki/Art-Net-Node_f%C3%BCr_25_Euro Art-Net-Node für 25 Euro]

=== Webserver von G. Menke ===

Ein Webserver (basierend auf den Sourcen von U. Radig), der so angepasst ist, dass alle Ein- und Ausgänge wie bei der originalen Pollin-Software genutzt werden können (8xDIGOUT, 4xDIGIN, 4xADIN). Der Webserver kann daher direkt auf das Net-IO geladen werden. Im ZIP-File sind ein ReadMe und alle C-Sourcen enthalten. Download:
[http://gm.stream-center.de/webserver/ Webserver mit passender IO]

=== OpenMCP ===

Tolles Projekt, welches viele Features bietet und stabil läuft. Hervorzuheben ist die Übersichtlichkeit der Programmteile/Module und die vielleicht nicht ganz komplette Dokumentation. Man merkt, dass viel Arbeit und Liebe in diesem Projekt steckt. Herausgekommen ist dabei eine einfach zu handhabende Entwicklungsumgebung. Anfänger können, dank des gut durchdachten CGI-Systems, welches sich um alle wichtigen Sachen kümmert, leicht eigene CGI implementieren. Alle Ausgaben erfolgen nur mit printf über die Standardausgabe und werden automatisch richtig per Netzwerk übertragen, dadurch ist es auch für den Anfänger recht gut geeignet, da man sich nicht mit der Netzwerkprogrammierung auseinander setzen muss.

Die Software belegt im Moment (Stand Juli 2010) ca. 55 Kb im Flash, so dass man das Board mit einem grösseren µC (z.B. ATMega644) aufrüsten muss.

[http://wiki.neo-guerillaz.de Projekt und Doku]

Der Autor stellt zwei über das Internet erreichbare Testboards bereit unter http://www.neo-guerillaz.de:81 und http://www.neo-guerillaz.de:82 die beide unter OpenMCP laufen, je auf einen AVR-NETIO mit einem ATmega644 und dem eigentlichen Board mit einem ATmega2561. Zusätzlich ist gerade eine Version für das myAVR in Arbeit die schon ordentlich Fortschritte macht.

=== OpenMLP ===
Auf openMCP basierender Port nach [http://avr.myluna.de LunaAVR] (GPL). Umfangreiche Funktionalität und direkte Anpassung an die Sprache. Abgespeckte Version auch auf Atmega32 lauffähig. Die Original-Dokumentation kann zum Großteil hergenommen werden. Einige Zusatzfeatures. Leichte Konfiguration und guter Einstieg für Anfänger und zum Verständnis der Serverfunktionalität.

[http://avr.myluna.de/doku.php?id=de:openmlp Artikelseite]
[http://forum.myluna.de/viewtopic.php?f=8&t=13 Forum]

=== ENC28J60 I/O-Webserver von Thomas Heldt ===

Ein Modul-Webserver (Softwarekompatibel zum Pollin Webserver), der durch div. Module erweitert werden kann, Software in Bascom basierend auf dem Code von Ben Zijlsta wurde erweitert und angepasst:

[http://mikrocontroller.heldt.eu/index.php?page=enc28j60-io-webserver Projekt und Software]

=== AVR-Netino ===
[http://code.google.com/p/avr-netino/ Projekt und Software]

Arduino fürs Net-IO

== Siehe auch ==
* Diskussion zu diesem Projekt: http://www.mikrocontroller.net/topic/109988
* [http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en022889 ENC28J60 Produktseite]
* [http://ww1.microchip.com/downloads/en/DeviceDoc/39662c.pdf ENC28J60 Datenblatt(pdf)]
* [http://son.ffdf-clan.de Forum für AVR-Net-IO]
* [http://avr.myluna.de/doku.php?id=de:openmlp LunaAVR openMLP ]
* [http://bascom-forum.de/index.php/topic,1781.0.html Bascom Forum ]
* [http://hobbyelektronik.org/w/index.php/AVR-NET-IO-Shield Shield für den NET-IO]

[[Category:AVR-Boards]]
[[Category:Ethernet|P]]

FAQ

2013-09-17T19:22:15Z

Kbuchegg:

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

itoa() ist keine C-Standardfunktion (wohl aber ihre Umkehrung atoi() ). Auf manchen Compilern heisst diese Funktion dann folgerichtig _itoa(), wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Libary [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

itoa( i, Buffer, 10 ); - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array Buffer groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei printf() (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

Typ ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
c char
d int
f float, double
ld long
u unsigned int
lu unsigned long
p pointer
s string
x ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
X ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

+ Vorzeichen wird immer ausgegeben
- Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
0 anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Werftebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man itoa() nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j 

Das Grundprinzip ist einfach: 
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> 2
8392 / 10 -> 839

839 % 10 -> 9
839 / 10 -> 83

83 % 10 -> 3
83 / 10 -> 8

8 % 10 -> 8
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j 

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit eien Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

=Aktivieren der Floating Point Version von sprintf beim WinAVR mit AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries'' In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous'' In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File, wie geht das? =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen. Für dieses System soll eine Aufteilung erfolgen, so dass funtionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionIntA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SettingB 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur eine Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. CTC Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte TOP). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

AVR-Tutorial: SRAM

2013-09-09T07:56:50Z

Kbuchegg: /* Beispiel */

==SRAM - Der Speicher des Controllers==

Nachdem in einem der vorangegangenen Kapitel eine [[AVR-Tutorial:_PWM|Software-PWM]] vorgestellt und in einem weiteren Kapitel darüber gesprochen wurde, wie man mit [[AVR-Tutorial:_Schieberegister|Schieberegistern]] die Anzahl an I/O-Pins erhöhen kann, wäre es naheliegend, beides zu kombinieren und den ATmega8 mal 20 oder 30 LEDs ansteuern zu lassen. Wenn es da nicht ein Problem gäbe: die Software-PWM hält ihre Daten in Registern, so wie das praktisch alle Programme bisher machten. Während allerdings 6 PWM-Kanäle noch problemlos in den Registern untergebracht werden konnten, ist dies mit 30 oder noch mehr PWM-Kanälen nicht mehr möglich. Es gibt schlicht und ergreifend nicht genug Register.

Es gibt aber einen Ausweg. Der ATmega8 verfügt über 1kByte '''SRAM''' (statisches RAM). Dieses RAM wurde bereits indirekt durch den '''Stack''' benutzt. Bei jedem Aufruf eines Unterprogrammes, sei es über einen expliziten '''CALL''' (bzw. '''RCALL''') oder einen Interrupt, wird die Rücksprungadresse irgendwo gespeichert. Dies geschieht genau in diesem SRAM. Auch '''PUSH''' und '''POP''' operieren in diesem Speicher.

Ein Programm darf Speicherzellen im '''SRAM''' direkt benutzen und dort Werte speichern bzw. von dort Werte einlesen. Es muss nur darauf geachtet werden, dass es zu keiner Kollision mit dem Stack kommt, in dem z. B. die erwähnten Rücksprungadressen für Unterprogramme gespeichert werden. Da viele Programme aber lediglich ein paar Byte '''SRAM''' brauchen, der Rücksprungstack von der oberen Grenze des '''SRAM''' nach unten wächst und der ATmega8 immerhin über '''1kByte''' '''SRAM''' verfügt, ist dies in der Praxis kein all zu großes Problem.

==Das .DSEG und .BYTE==
Um dem Assembler mitzuteilen, dass sich der folgende Abschnitt auf das SRAM bezieht, gibt es die Direktive '''.DSEG''' (Data Segment). Alle nach einer '''.DSEG''' Direktive folgenden Speicherreservierungen werden vom Assembler im SRAM durchgeführt.

Die Direktive '''.BYTE''' stellt dabei eine derartige Speicherreservierung dar. Es ermöglicht, der Speicherreservierung einen Namen zu geben und es erlaubt auch, nicht nur 1 Byte sondern eine ganze Reihe von Bytes unter einem Namen zu reservieren.

<syntaxhighlight lang="avrasm">
.DSEG ; Umschalten auf das SRAM Datensegment
Counter: .BYTE 1 ; 1 Byte unter dem Namen 'Counter' reservieren
Test: .BYTE 20 ; 20 Byte unter dem Namen 'Test' reservieren
</syntaxhighlight>

==spezielle Befehle==
Für den Zugriff auf den '''SRAM'''-Speicher gibt es spezielle Befehle. Diese holen entweder den momentanen Inhalt einer Speicherzelle und legen ihn in einem Register ab oder legen den Inhalt eines Registers in einer '''SRAM'''-Speicherzelle ab.

===LDS===
Liest die angegebene '''SRAM'''-Speicherzelle und legt den gelesenen Wert in einem Register ab.

<syntaxhighlight lang="avrasm">
LDS r17, Counter ; liest die Speicherzelle mit dem Namen 'Counter'
; und legt den gelesenen Wert im Register r17 ab
</syntaxhighlight>

===STS===
Legt den in einem Register gespeicherten Wert in einer '''SRAM'''-Speicherzelle ab.

<syntaxhighlight lang="avrasm">
STS Counter, r17 ; Speichert den Inhalt von r17 in der
; Speicherzelle 'Counter'
</syntaxhighlight>

===Beispiel===

Eine mögliche Implementierung der [[AVR-Tutorial:_PWM|Software-PWM]], die den PWM-Zähler sowie die einzelnen OCR-Grenzwerte im '''SRAM''' anstelle von Registern speichert, könnte z. B. so aussehen:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi temp2, 0
sts OCR_1, temp2
ldi temp2, 1
sts OCR_2, temp2
ldi temp2, 10
sts OCR_3, temp2
ldi temp2, 20
sts OCR_4, temp2
ldi temp2, 80
sts OCR_5, temp2
ldi temp2, 127
sts OCR_6, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

; *************************************************************************
; Behandlung des Timer Overflows
;
; realisiert die PWM auf 6 Kanälen
;
; veränderte Register: keine
;
timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM-Zaehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM-Zaehler wieder auf 0

WorkPWM:
sts PWMCount, temp1 ; den PWM-Zaehler wieder speichern
ldi temp, 0b11000000 ; 0 .. LED an, 1 .. LED aus

lds temp2, OCR_1
cp temp1, temp2 ; Ist der Grenzwert für LED 1 erreicht
brlt OneOn
ori temp, $01

OneOn: lds temp2, OCR_2
cp temp1, temp2 ; Ist der Grenzwert für LED 2 erreicht
brlt TwoOn
ori temp, $02

TwoOn: lds temp2, OCR_3
cp temp1, temp2 ; Ist der Grenzwert für LED 3 erreicht
brlt ThreeOn
ori temp, $04

ThreeOn:lds temp2, OCR_4
cp temp1, temp2 ; Ist der Grenzwert für LED 4 erreicht
brlt FourOn
ori temp, $08

FourOn: lds temp2, OCR_5
cp temp1, temp2 ; Ist der Grenzwert für LED 5 erreicht
brlt FiveOn
ori temp, $10

FiveOn: lds temp2, OCR_6
cp temp1, temp2 ; Ist der Grenzwert für LED 6 erreicht
brlt SetBits
ori temp, $20

SetBits: ; Die neue Bitbelegung am Port ausgeben
out PORTB, temp

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop temp2
pop temp1
pop temp

reti
;
; **********************************************
;
.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; Der PWM-Counter (0 bis 127)
OCR_1: .BYTE 1 ; 6 Bytes für die OCR-Register
OCR_2: .BYTE 1
OCR_3: .BYTE 1
OCR_4: .BYTE 1
OCR_5: .BYTE 1
OCR_6: .BYTE 1
</syntaxhighlight>

Die ISR sichert alle verwendeten Register und stellt sie am Ende der ISR wieder her. Dies ist zwar streng genommen in diesem Beispiel nicht notwendig, da das eigentliche Programm in der Hauptschleife ja nichts tut, aber ausser ein bischen Zeit kostet das nichts und es erspart das Kopfkratzen, wenn dann irgendwann in der Hauptschleife Ergänzungen und anderer Code dazu kommen. Man kann natürlich einige Register speziell für die Verwendung ausschliesslich in der ISR reservieren und sich so das Sichern/Wiederherstellen ersparen, aber das SREG muss im Normalfall innerhalb einer ISR auf jeden Fall gesichert und wiederhergestellt werden.

==Spezielle Register==
===Der Z-Pointer (R30 und R31)===
Das Registerpärchen '''R30''' und '''R31''' kann zu einem einzigen logischen Register zusammengefasst werden und heisst dann '''Z-Pointer'''. Diesem kann eine spezielle Aufgabe zukommen, indem er als Adressangabe fungieren kann, von welcher Speicherzelle im SRAM ein Ladevorgang (bzw. Speichervorgang) durchgeführt werden soll. Anstatt die Speicheradresse wie beim '''LDS''' bzw. '''STS''' direkt im Programmcode anzugeben, kann diese Speicheradresse zunächst in den '''Z-Pointer''' geladen werden und der Lesevorgang (Schreibvorgang) über diesen '''Z-Pointer''' abgewickelt werden. Dadurch wird aber die '''SRAM'''-Speicheradresse berechenbar, denn natürlich kann mit den Registern '''R30''' und '''R31''', wie mit den anderen Registern auch, Arithmetik betrieben werden. Besonders komfortabel ist dies, da im Ladebefehl noch zusätzliche Manipulationen angegeben werden können, die oft benötigte arithmetische Operationen implementieren.

===LD===

* '''LD rxx, Z'''
* '''LD rxx, Z+'''
* '''LD rxx, -Z'''

Lädt das Register '''rxx''' mit dem Inhalt der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===LDD===
* '''LDD rxx, Z+q'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Ladeanweisung

<syntaxhighlight lang="avrasm">
LDD r18, Z + $28
</syntaxhighlight>

der Inhalt der Speicherzellen $1000 + $28 = $1028 in das Register r18 geladen.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===ST===

* '''ST Z, rxx'''
* '''ST Z+, rxx'''
* '''ST -Z, rxx'''

Speichert den Inhalt des Register '''rxx''' in der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===STD===
* '''STD Z+q, rxx'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Speicheranweisung
<syntaxhighlight lang="avrasm">
STD Z + $28, r18
</syntaxhighlight>

der Inhalt des Registers r18 in der Speicherzellen $1000 + $28 = $1028 gespeichert.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===Beispiel===

Durch Verwendung des '''Z-Pointers''' ist es möglich die Interrupt Funktion wesentlich kürzer und vor allem ohne ständige Wiederholung von im Prinzip immer gleichem Code zu formulieren. Man stelle sich nur mal vor wie dieser Code aussehen würde, wenn anstelle von 6 PWM Stufen, deren 40 gebraucht würden. Mit dem '''Z-Pointer''' ist es möglich diesen auf das erste der OCR Bytes zu setzen und dann in einer Schleife eines nach dem anderen abzuarbeiten. Nach dem Laden des jeweiligen OCR Wertes, wird der '''Z-Pointer''' automatisch durch den '''LD'''-Befehl auf das nächste zu verarbeitende OCR Byte weitergezählt.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18
.def temp3 = r19

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)

ldi temp2, 0
st Z+, temp2
ldi temp2, 1
st Z+, temp2
ldi temp2, 10
st Z+, temp2
ldi temp2, 20
st Z+, temp2
ldi temp2, 80
st Z+, temp2
ldi temp2, 127
st Z+, temp2

ldi temp2, 0 ; den PWM Counter auf 0 setzen
sts PWMCount, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

; *************************************************************************
; Behandlung des Timer Overflows
;
; realisiert die PWM auf 6 Kanälen
;
; veränderte Register: keine
;
timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
push R30
push R31
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM ZAehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM Zaehler auf 0 setzen

WorkPWM:
sts PWMCount, temp1 ; den PWM Zaehler wieder speichern

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)
ldi temp3, $01 ; das Bitmuster für PWM Nr. i
ldi temp, 0b11000000 ; 0 .. Led an, 1 .. Led aus

pwmloop:
ld temp2, Z+ ; den OCR Wert für PWM Nr. i holen und Z-Pointer erhöhen
cp temp1, temp2 ; ist der Grenzwert für PWM Nr. i erreicht?
brlo LedOn
or temp, temp3
LedOn:
lsl temp3 ; das Bitmuster schieben
cpi temp3, $40 ; alle Bits behandelt ?
brne pwmloop ; nächster Schleifendurchlauf

out PORTB, temp ; Die neue Bitbelegung am Port ausgeben

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop R31
pop R30
pop temp2
pop temp1
pop temp

reti
;
; *********************************************************************
;
.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; der PWM Zaehler (0 bis 127)
OCR: .BYTE 6 ; 6 Bytes für die OCR Register

</syntaxhighlight>

===X-Pointer, Y-Pointer===
Neben dem '''Z-Pointer''' gibt es noch den '''X-Pointer''' bzw. '''Y-Pointer'''. Sie werden gebildet von den Registerpärchen
* '''X-Pointer''': r26, r27
* '''Y-Pointer''': r28, r29
* '''Z-Pointer''': r30, r31
Alles über den '''Z-Pointer''' gesagte gilt sinngemäß auch für den '''X-Pointer''' bzw. '''Y-Pointer''' mit einer Ausnahme: Mit dem '''X-Pointer''' ist kein Zugriff '''LDD'''/'''STD''' mit einem Displacement möglich.

== Siehe auch ==
* [[Adressierung]]

----

{{Navigation_zurückhochvor|
zurücktext=Schieberegister|
zurücklink=AVR-Tutorial: Schieberegister|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=7-Segment-Anzeige|
vorlink=AVR-Tutorial: 7-Segment-Anzeige}}

[[Category:AVR-Tutorial|SRAM]]

AVR-Tutorial: SRAM

2013-09-09T07:53:34Z

Kbuchegg: /* Beispiel */

==SRAM - Der Speicher des Controllers==

Nachdem in einem der vorangegangenen Kapitel eine [[AVR-Tutorial:_PWM|Software-PWM]] vorgestellt und in einem weiteren Kapitel darüber gesprochen wurde, wie man mit [[AVR-Tutorial:_Schieberegister|Schieberegistern]] die Anzahl an I/O-Pins erhöhen kann, wäre es naheliegend, beides zu kombinieren und den ATmega8 mal 20 oder 30 LEDs ansteuern zu lassen. Wenn es da nicht ein Problem gäbe: die Software-PWM hält ihre Daten in Registern, so wie das praktisch alle Programme bisher machten. Während allerdings 6 PWM-Kanäle noch problemlos in den Registern untergebracht werden konnten, ist dies mit 30 oder noch mehr PWM-Kanälen nicht mehr möglich. Es gibt schlicht und ergreifend nicht genug Register.

Es gibt aber einen Ausweg. Der ATmega8 verfügt über 1kByte '''SRAM''' (statisches RAM). Dieses RAM wurde bereits indirekt durch den '''Stack''' benutzt. Bei jedem Aufruf eines Unterprogrammes, sei es über einen expliziten '''CALL''' (bzw. '''RCALL''') oder einen Interrupt, wird die Rücksprungadresse irgendwo gespeichert. Dies geschieht genau in diesem SRAM. Auch '''PUSH''' und '''POP''' operieren in diesem Speicher.

Ein Programm darf Speicherzellen im '''SRAM''' direkt benutzen und dort Werte speichern bzw. von dort Werte einlesen. Es muss nur darauf geachtet werden, dass es zu keiner Kollision mit dem Stack kommt, in dem z. B. die erwähnten Rücksprungadressen für Unterprogramme gespeichert werden. Da viele Programme aber lediglich ein paar Byte '''SRAM''' brauchen, der Rücksprungstack von der oberen Grenze des '''SRAM''' nach unten wächst und der ATmega8 immerhin über '''1kByte''' '''SRAM''' verfügt, ist dies in der Praxis kein all zu großes Problem.

==Das .DSEG und .BYTE==
Um dem Assembler mitzuteilen, dass sich der folgende Abschnitt auf das SRAM bezieht, gibt es die Direktive '''.DSEG''' (Data Segment). Alle nach einer '''.DSEG''' Direktive folgenden Speicherreservierungen werden vom Assembler im SRAM durchgeführt.

Die Direktive '''.BYTE''' stellt dabei eine derartige Speicherreservierung dar. Es ermöglicht, der Speicherreservierung einen Namen zu geben und es erlaubt auch, nicht nur 1 Byte sondern eine ganze Reihe von Bytes unter einem Namen zu reservieren.

<syntaxhighlight lang="avrasm">
.DSEG ; Umschalten auf das SRAM Datensegment
Counter: .BYTE 1 ; 1 Byte unter dem Namen 'Counter' reservieren
Test: .BYTE 20 ; 20 Byte unter dem Namen 'Test' reservieren
</syntaxhighlight>

==spezielle Befehle==
Für den Zugriff auf den '''SRAM'''-Speicher gibt es spezielle Befehle. Diese holen entweder den momentanen Inhalt einer Speicherzelle und legen ihn in einem Register ab oder legen den Inhalt eines Registers in einer '''SRAM'''-Speicherzelle ab.

===LDS===
Liest die angegebene '''SRAM'''-Speicherzelle und legt den gelesenen Wert in einem Register ab.

<syntaxhighlight lang="avrasm">
LDS r17, Counter ; liest die Speicherzelle mit dem Namen 'Counter'
; und legt den gelesenen Wert im Register r17 ab
</syntaxhighlight>

===STS===
Legt den in einem Register gespeicherten Wert in einer '''SRAM'''-Speicherzelle ab.

<syntaxhighlight lang="avrasm">
STS Counter, r17 ; Speichert den Inhalt von r17 in der
; Speicherzelle 'Counter'
</syntaxhighlight>

===Beispiel===

Eine mögliche Implementierung der [[AVR-Tutorial:_PWM|Software-PWM]], die den PWM-Zähler sowie die einzelnen OCR-Grenzwerte im '''SRAM''' anstelle von Registern speichert, könnte z. B. so aussehen:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi temp2, 0
sts OCR_1, temp2
ldi temp2, 1
sts OCR_2, temp2
ldi temp2, 10
sts OCR_3, temp2
ldi temp2, 20
sts OCR_4, temp2
ldi temp2, 80
sts OCR_5, temp2
ldi temp2, 127
sts OCR_6, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

; *************************************************************************
; Behandlung des Timer Overflows
;
; realisiert die PWM auf 6 Kanälen
;
; veränderte Register: keine
;
timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM-Zaehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM-Zaehler wieder auf 0

WorkPWM:
sts PWMCount, temp1 ; den PWM-Zaehler wieder speichern
ldi temp, 0b11000000 ; 0 .. LED an, 1 .. LED aus

lds temp2, OCR_1
cp temp1, temp2 ; Ist der Grenzwert für LED 1 erreicht
brlt OneOn
ori temp, $01

OneOn: lds temp2, OCR_2
cp temp1, temp2 ; Ist der Grenzwert für LED 2 erreicht
brlt TwoOn
ori temp, $02

TwoOn: lds temp2, OCR_3
cp temp1, temp2 ; Ist der Grenzwert für LED 3 erreicht
brlt ThreeOn
ori temp, $04

ThreeOn:lds temp2, OCR_4
cp temp1, temp2 ; Ist der Grenzwert für LED 4 erreicht
brlt FourOn
ori temp, $08

FourOn: lds temp2, OCR_5
cp temp1, temp2 ; Ist der Grenzwert für LED 5 erreicht
brlt FiveOn
ori temp, $10

FiveOn: lds temp2, OCR_6
cp temp1, temp2 ; Ist der Grenzwert für LED 6 erreicht
brlt SetBits
ori temp, $20

SetBits: ; Die neue Bitbelegung am Port ausgeben
out PORTB, temp

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop temp2
pop temp1
pop temp

reti
;
; **********************************************
;
.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; Der PWM-Counter (0 bis 127)
OCR_1: .BYTE 1 ; 6 Bytes für die OCR-Register
OCR_2: .BYTE 1
OCR_3: .BYTE 1
OCR_4: .BYTE 1
OCR_5: .BYTE 1
OCR_6: .BYTE 1
</syntaxhighlight>

==Spezielle Register==
===Der Z-Pointer (R30 und R31)===
Das Registerpärchen '''R30''' und '''R31''' kann zu einem einzigen logischen Register zusammengefasst werden und heisst dann '''Z-Pointer'''. Diesem kann eine spezielle Aufgabe zukommen, indem er als Adressangabe fungieren kann, von welcher Speicherzelle im SRAM ein Ladevorgang (bzw. Speichervorgang) durchgeführt werden soll. Anstatt die Speicheradresse wie beim '''LDS''' bzw. '''STS''' direkt im Programmcode anzugeben, kann diese Speicheradresse zunächst in den '''Z-Pointer''' geladen werden und der Lesevorgang (Schreibvorgang) über diesen '''Z-Pointer''' abgewickelt werden. Dadurch wird aber die '''SRAM'''-Speicheradresse berechenbar, denn natürlich kann mit den Registern '''R30''' und '''R31''', wie mit den anderen Registern auch, Arithmetik betrieben werden. Besonders komfortabel ist dies, da im Ladebefehl noch zusätzliche Manipulationen angegeben werden können, die oft benötigte arithmetische Operationen implementieren.

===LD===

* '''LD rxx, Z'''
* '''LD rxx, Z+'''
* '''LD rxx, -Z'''

Lädt das Register '''rxx''' mit dem Inhalt der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===LDD===
* '''LDD rxx, Z+q'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Ladeanweisung

<syntaxhighlight lang="avrasm">
LDD r18, Z + $28
</syntaxhighlight>

der Inhalt der Speicherzellen $1000 + $28 = $1028 in das Register r18 geladen.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===ST===

* '''ST Z, rxx'''
* '''ST Z+, rxx'''
* '''ST -Z, rxx'''

Speichert den Inhalt des Register '''rxx''' in der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===STD===
* '''STD Z+q, rxx'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Speicheranweisung
<syntaxhighlight lang="avrasm">
STD Z + $28, r18
</syntaxhighlight>

der Inhalt des Registers r18 in der Speicherzellen $1000 + $28 = $1028 gespeichert.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===Beispiel===

Durch Verwendung des '''Z-Pointers''' ist es möglich die Interrupt Funktion wesentlich kürzer und vor allem ohne ständige Wiederholung von im Prinzip immer gleichem Code zu formulieren. Man stelle sich nur mal vor wie dieser Code aussehen würde, wenn anstelle von 6 PWM Stufen, deren 40 gebraucht würden. Mit dem '''Z-Pointer''' ist es möglich diesen auf das erste der OCR Bytes zu setzen und dann in einer Schleife eines nach dem anderen abzuarbeiten. Nach dem Laden des jeweiligen OCR Wertes, wird der '''Z-Pointer''' automatisch durch den '''LD'''-Befehl auf das nächste zu verarbeitende OCR Byte weitergezählt.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18
.def temp3 = r19

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)

ldi temp2, 0
st Z+, temp2
ldi temp2, 1
st Z+, temp2
ldi temp2, 10
st Z+, temp2
ldi temp2, 20
st Z+, temp2
ldi temp2, 80
st Z+, temp2
ldi temp2, 127
st Z+, temp2

ldi temp2, 0 ; den PWM Counter auf 0 setzen
sts PWMCount, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

; *************************************************************************
; Behandlung des Timer Overflows
;
; realisiert die PWM auf 6 Kanälen
;
; veränderte Register: keine
;
timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
push R30
push R31
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM ZAehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM Zaehler auf 0 setzen

WorkPWM:
sts PWMCount, temp1 ; den PWM Zaehler wieder speichern

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)
ldi temp3, $01 ; das Bitmuster für PWM Nr. i
ldi temp, 0b11000000 ; 0 .. Led an, 1 .. Led aus

pwmloop:
ld temp2, Z+ ; den OCR Wert für PWM Nr. i holen und Z-Pointer erhöhen
cp temp1, temp2 ; ist der Grenzwert für PWM Nr. i erreicht?
brlo LedOn
or temp, temp3
LedOn:
lsl temp3 ; das Bitmuster schieben
cpi temp3, $40 ; alle Bits behandelt ?
brne pwmloop ; nächster Schleifendurchlauf

out PORTB, temp ; Die neue Bitbelegung am Port ausgeben

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop R31
pop R30
pop temp2
pop temp1
pop temp

reti
;
; *********************************************************************
;
.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; der PWM Zaehler (0 bis 127)
OCR: .BYTE 6 ; 6 Bytes für die OCR Register

</syntaxhighlight>

===X-Pointer, Y-Pointer===
Neben dem '''Z-Pointer''' gibt es noch den '''X-Pointer''' bzw. '''Y-Pointer'''. Sie werden gebildet von den Registerpärchen
* '''X-Pointer''': r26, r27
* '''Y-Pointer''': r28, r29
* '''Z-Pointer''': r30, r31
Alles über den '''Z-Pointer''' gesagte gilt sinngemäß auch für den '''X-Pointer''' bzw. '''Y-Pointer''' mit einer Ausnahme: Mit dem '''X-Pointer''' ist kein Zugriff '''LDD'''/'''STD''' mit einem Displacement möglich.

== Siehe auch ==
* [[Adressierung]]

----

{{Navigation_zurückhochvor|
zurücktext=Schieberegister|
zurücklink=AVR-Tutorial: Schieberegister|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=7-Segment-Anzeige|
vorlink=AVR-Tutorial: 7-Segment-Anzeige}}

[[Category:AVR-Tutorial|SRAM]]

AVR-Tutorial: SRAM

2013-09-09T07:51:27Z

Kbuchegg: /* Beispiel */

==SRAM - Der Speicher des Controllers==

Nachdem in einem der vorangegangenen Kapitel eine [[AVR-Tutorial:_PWM|Software-PWM]] vorgestellt und in einem weiteren Kapitel darüber gesprochen wurde, wie man mit [[AVR-Tutorial:_Schieberegister|Schieberegistern]] die Anzahl an I/O-Pins erhöhen kann, wäre es naheliegend, beides zu kombinieren und den ATmega8 mal 20 oder 30 LEDs ansteuern zu lassen. Wenn es da nicht ein Problem gäbe: die Software-PWM hält ihre Daten in Registern, so wie das praktisch alle Programme bisher machten. Während allerdings 6 PWM-Kanäle noch problemlos in den Registern untergebracht werden konnten, ist dies mit 30 oder noch mehr PWM-Kanälen nicht mehr möglich. Es gibt schlicht und ergreifend nicht genug Register.

Es gibt aber einen Ausweg. Der ATmega8 verfügt über 1kByte '''SRAM''' (statisches RAM). Dieses RAM wurde bereits indirekt durch den '''Stack''' benutzt. Bei jedem Aufruf eines Unterprogrammes, sei es über einen expliziten '''CALL''' (bzw. '''RCALL''') oder einen Interrupt, wird die Rücksprungadresse irgendwo gespeichert. Dies geschieht genau in diesem SRAM. Auch '''PUSH''' und '''POP''' operieren in diesem Speicher.

Ein Programm darf Speicherzellen im '''SRAM''' direkt benutzen und dort Werte speichern bzw. von dort Werte einlesen. Es muss nur darauf geachtet werden, dass es zu keiner Kollision mit dem Stack kommt, in dem z. B. die erwähnten Rücksprungadressen für Unterprogramme gespeichert werden. Da viele Programme aber lediglich ein paar Byte '''SRAM''' brauchen, der Rücksprungstack von der oberen Grenze des '''SRAM''' nach unten wächst und der ATmega8 immerhin über '''1kByte''' '''SRAM''' verfügt, ist dies in der Praxis kein all zu großes Problem.

==Das .DSEG und .BYTE==
Um dem Assembler mitzuteilen, dass sich der folgende Abschnitt auf das SRAM bezieht, gibt es die Direktive '''.DSEG''' (Data Segment). Alle nach einer '''.DSEG''' Direktive folgenden Speicherreservierungen werden vom Assembler im SRAM durchgeführt.

Die Direktive '''.BYTE''' stellt dabei eine derartige Speicherreservierung dar. Es ermöglicht, der Speicherreservierung einen Namen zu geben und es erlaubt auch, nicht nur 1 Byte sondern eine ganze Reihe von Bytes unter einem Namen zu reservieren.

<syntaxhighlight lang="avrasm">
.DSEG ; Umschalten auf das SRAM Datensegment
Counter: .BYTE 1 ; 1 Byte unter dem Namen 'Counter' reservieren
Test: .BYTE 20 ; 20 Byte unter dem Namen 'Test' reservieren
</syntaxhighlight>

==spezielle Befehle==
Für den Zugriff auf den '''SRAM'''-Speicher gibt es spezielle Befehle. Diese holen entweder den momentanen Inhalt einer Speicherzelle und legen ihn in einem Register ab oder legen den Inhalt eines Registers in einer '''SRAM'''-Speicherzelle ab.

===LDS===
Liest die angegebene '''SRAM'''-Speicherzelle und legt den gelesenen Wert in einem Register ab.

<syntaxhighlight lang="avrasm">
LDS r17, Counter ; liest die Speicherzelle mit dem Namen 'Counter'
; und legt den gelesenen Wert im Register r17 ab
</syntaxhighlight>

===STS===
Legt den in einem Register gespeicherten Wert in einer '''SRAM'''-Speicherzelle ab.

<syntaxhighlight lang="avrasm">
STS Counter, r17 ; Speichert den Inhalt von r17 in der
; Speicherzelle 'Counter'
</syntaxhighlight>

===Beispiel===

Eine mögliche Implementierung der [[AVR-Tutorial:_PWM|Software-PWM]], die den PWM-Zähler sowie die einzelnen OCR-Grenzwerte im '''SRAM''' anstelle von Registern speichert, könnte z. B. so aussehen:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi temp2, 0
sts OCR_1, temp2
ldi temp2, 1
sts OCR_2, temp2
ldi temp2, 10
sts OCR_3, temp2
ldi temp2, 20
sts OCR_4, temp2
ldi temp2, 80
sts OCR_5, temp2
ldi temp2, 127
sts OCR_6, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

; *************************************************************************
; Behandlung des Timer Overflows
;
; realisiert die PWM auf 6 Kanälen
;
; veränderte Register: keine
;
timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM-Zaehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM-Zaehler wieder auf 0

WorkPWM:
sts PWMCount, temp1 ; den PWM-Zaehler wieder speichern
ldi temp, 0b11000000 ; 0 .. LED an, 1 .. LED aus

lds temp2, OCR_1
cp temp1, temp2 ; Ist der Grenzwert für LED 1 erreicht
brlt OneOn
ori temp, $01

OneOn: lds temp2, OCR_2
cp temp1, temp2 ; Ist der Grenzwert für LED 2 erreicht
brlt TwoOn
ori temp, $02

TwoOn: lds temp2, OCR_3
cp temp1, temp2 ; Ist der Grenzwert für LED 3 erreicht
brlt ThreeOn
ori temp, $04

ThreeOn:lds temp2, OCR_4
cp temp1, temp2 ; Ist der Grenzwert für LED 4 erreicht
brlt FourOn
ori temp, $08

FourOn: lds temp2, OCR_5
cp temp1, temp2 ; Ist der Grenzwert für LED 5 erreicht
brlt FiveOn
ori temp, $10

FiveOn: lds temp2, OCR_6
cp temp1, temp2 ; Ist der Grenzwert für LED 6 erreicht
brlt SetBits
ori temp, $20

SetBits: ; Die neue Bitbelegung am Port ausgeben
out PORTB, temp

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop temp2
pop temp1
pop temp

reti
;
; **********************************************
;
.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; Der PWM-Counter (0 bis 127)
OCR_1: .BYTE 1 ; 6 Bytes für die OCR-Register
OCR_2: .BYTE 1
OCR_3: .BYTE 1
OCR_4: .BYTE 1
OCR_5: .BYTE 1
OCR_6: .BYTE 1
</syntaxhighlight>

==Spezielle Register==
===Der Z-Pointer (R30 und R31)===
Das Registerpärchen '''R30''' und '''R31''' kann zu einem einzigen logischen Register zusammengefasst werden und heisst dann '''Z-Pointer'''. Diesem kann eine spezielle Aufgabe zukommen, indem er als Adressangabe fungieren kann, von welcher Speicherzelle im SRAM ein Ladevorgang (bzw. Speichervorgang) durchgeführt werden soll. Anstatt die Speicheradresse wie beim '''LDS''' bzw. '''STS''' direkt im Programmcode anzugeben, kann diese Speicheradresse zunächst in den '''Z-Pointer''' geladen werden und der Lesevorgang (Schreibvorgang) über diesen '''Z-Pointer''' abgewickelt werden. Dadurch wird aber die '''SRAM'''-Speicheradresse berechenbar, denn natürlich kann mit den Registern '''R30''' und '''R31''', wie mit den anderen Registern auch, Arithmetik betrieben werden. Besonders komfortabel ist dies, da im Ladebefehl noch zusätzliche Manipulationen angegeben werden können, die oft benötigte arithmetische Operationen implementieren.

===LD===

* '''LD rxx, Z'''
* '''LD rxx, Z+'''
* '''LD rxx, -Z'''

Lädt das Register '''rxx''' mit dem Inhalt der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===LDD===
* '''LDD rxx, Z+q'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Ladeanweisung

<syntaxhighlight lang="avrasm">
LDD r18, Z + $28
</syntaxhighlight>

der Inhalt der Speicherzellen $1000 + $28 = $1028 in das Register r18 geladen.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===ST===

* '''ST Z, rxx'''
* '''ST Z+, rxx'''
* '''ST -Z, rxx'''

Speichert den Inhalt des Register '''rxx''' in der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===STD===
* '''STD Z+q, rxx'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Speicheranweisung
<syntaxhighlight lang="avrasm">
STD Z + $28, r18
</syntaxhighlight>

der Inhalt des Registers r18 in der Speicherzellen $1000 + $28 = $1028 gespeichert.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===Beispiel===

Durch Verwendung des '''Z-Pointers''' ist es möglich die Interrupt Funktion wesentlich kürzer und vor allem ohne ständige Wiederholung von im Prinzip immer gleichem Code zu formulieren. Man stelle sich nur mal vor wie dieser Code aussehen würde, wenn anstelle von 6 PWM Stufen, deren 40 gebraucht würden. Mit dem '''Z-Pointer''' ist es möglich diesen auf das erste der OCR Bytes zu setzen und dann in einer Schleife eines nach dem anderen abzuarbeiten. Nach dem Laden des jeweiligen OCR Wertes, wird der '''Z-Pointer''' automatisch durch den '''LD'''-Befehl auf das nächste zu verarbeitende OCR Byte weitergezählt.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18
.def temp3 = r19

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)

ldi temp2, 0
st Z+, temp2
ldi temp2, 1
st Z+, temp2
ldi temp2, 10
st Z+, temp2
ldi temp2, 20
st Z+, temp2
ldi temp2, 80
st Z+, temp2
ldi temp2, 127
st Z+, temp2

ldi temp2, 0 ; den PWM Counter auf 0 setzen
sts PWMCount, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

; *************************************************************************
; Behandlung des Timer Overflows
;
; realisiert die PWM auf 6 Kanälen
;
; veränderte Register: keine
;
timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM ZAehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM Zaehler auf 0 setzen

WorkPWM:
sts PWMCount, temp1 ; den PWM Zaehler wieder speichern

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)
ldi temp3, $01 ; das Bitmuster für PWM Nr. i
ldi temp, 0b11000000 ; 0 .. Led an, 1 .. Led aus

pwmloop:
ld temp2, Z+ ; den OCR Wert für PWM Nr. i holen und Z-Pointer erhöhen
cp temp1, temp2 ; ist der Grenzwert für PWM Nr. i erreicht?
brlo LedOn
or temp, temp3
LedOn:
lsl temp3 ; das Bitmuster schieben
cpi temp3, $40 ; alle Bits behandelt ?
brne pwmloop ; nächster Schleifendurchlauf

out PORTB, temp ; Die neue Bitbelegung am Port ausgeben

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop temp2
pop temp1
pop temp

reti
;
; *********************************************************************
;
.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; der PWM Zaehler (0 bis 127)
OCR: .BYTE 6 ; 6 Bytes für die OCR Register

</syntaxhighlight>

===X-Pointer, Y-Pointer===
Neben dem '''Z-Pointer''' gibt es noch den '''X-Pointer''' bzw. '''Y-Pointer'''. Sie werden gebildet von den Registerpärchen
* '''X-Pointer''': r26, r27
* '''Y-Pointer''': r28, r29
* '''Z-Pointer''': r30, r31
Alles über den '''Z-Pointer''' gesagte gilt sinngemäß auch für den '''X-Pointer''' bzw. '''Y-Pointer''' mit einer Ausnahme: Mit dem '''X-Pointer''' ist kein Zugriff '''LDD'''/'''STD''' mit einem Displacement möglich.

== Siehe auch ==
* [[Adressierung]]

----

{{Navigation_zurückhochvor|
zurücktext=Schieberegister|
zurücklink=AVR-Tutorial: Schieberegister|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=7-Segment-Anzeige|
vorlink=AVR-Tutorial: 7-Segment-Anzeige}}

[[Category:AVR-Tutorial|SRAM]]

AVR-Tutorial: SRAM

2013-09-09T07:50:04Z

Kbuchegg: /* Beispiel */

==SRAM - Der Speicher des Controllers==

Nachdem in einem der vorangegangenen Kapitel eine [[AVR-Tutorial:_PWM|Software-PWM]] vorgestellt und in einem weiteren Kapitel darüber gesprochen wurde, wie man mit [[AVR-Tutorial:_Schieberegister|Schieberegistern]] die Anzahl an I/O-Pins erhöhen kann, wäre es naheliegend, beides zu kombinieren und den ATmega8 mal 20 oder 30 LEDs ansteuern zu lassen. Wenn es da nicht ein Problem gäbe: die Software-PWM hält ihre Daten in Registern, so wie das praktisch alle Programme bisher machten. Während allerdings 6 PWM-Kanäle noch problemlos in den Registern untergebracht werden konnten, ist dies mit 30 oder noch mehr PWM-Kanälen nicht mehr möglich. Es gibt schlicht und ergreifend nicht genug Register.

Es gibt aber einen Ausweg. Der ATmega8 verfügt über 1kByte '''SRAM''' (statisches RAM). Dieses RAM wurde bereits indirekt durch den '''Stack''' benutzt. Bei jedem Aufruf eines Unterprogrammes, sei es über einen expliziten '''CALL''' (bzw. '''RCALL''') oder einen Interrupt, wird die Rücksprungadresse irgendwo gespeichert. Dies geschieht genau in diesem SRAM. Auch '''PUSH''' und '''POP''' operieren in diesem Speicher.

Ein Programm darf Speicherzellen im '''SRAM''' direkt benutzen und dort Werte speichern bzw. von dort Werte einlesen. Es muss nur darauf geachtet werden, dass es zu keiner Kollision mit dem Stack kommt, in dem z. B. die erwähnten Rücksprungadressen für Unterprogramme gespeichert werden. Da viele Programme aber lediglich ein paar Byte '''SRAM''' brauchen, der Rücksprungstack von der oberen Grenze des '''SRAM''' nach unten wächst und der ATmega8 immerhin über '''1kByte''' '''SRAM''' verfügt, ist dies in der Praxis kein all zu großes Problem.

==Das .DSEG und .BYTE==
Um dem Assembler mitzuteilen, dass sich der folgende Abschnitt auf das SRAM bezieht, gibt es die Direktive '''.DSEG''' (Data Segment). Alle nach einer '''.DSEG''' Direktive folgenden Speicherreservierungen werden vom Assembler im SRAM durchgeführt.

Die Direktive '''.BYTE''' stellt dabei eine derartige Speicherreservierung dar. Es ermöglicht, der Speicherreservierung einen Namen zu geben und es erlaubt auch, nicht nur 1 Byte sondern eine ganze Reihe von Bytes unter einem Namen zu reservieren.

<syntaxhighlight lang="avrasm">
.DSEG ; Umschalten auf das SRAM Datensegment
Counter: .BYTE 1 ; 1 Byte unter dem Namen 'Counter' reservieren
Test: .BYTE 20 ; 20 Byte unter dem Namen 'Test' reservieren
</syntaxhighlight>

==spezielle Befehle==
Für den Zugriff auf den '''SRAM'''-Speicher gibt es spezielle Befehle. Diese holen entweder den momentanen Inhalt einer Speicherzelle und legen ihn in einem Register ab oder legen den Inhalt eines Registers in einer '''SRAM'''-Speicherzelle ab.

===LDS===
Liest die angegebene '''SRAM'''-Speicherzelle und legt den gelesenen Wert in einem Register ab.

<syntaxhighlight lang="avrasm">
LDS r17, Counter ; liest die Speicherzelle mit dem Namen 'Counter'
; und legt den gelesenen Wert im Register r17 ab
</syntaxhighlight>

===STS===
Legt den in einem Register gespeicherten Wert in einer '''SRAM'''-Speicherzelle ab.

<syntaxhighlight lang="avrasm">
STS Counter, r17 ; Speichert den Inhalt von r17 in der
; Speicherzelle 'Counter'
</syntaxhighlight>

===Beispiel===

Eine mögliche Implementierung der [[AVR-Tutorial:_PWM|Software-PWM]], die den PWM-Zähler sowie die einzelnen OCR-Grenzwerte im '''SRAM''' anstelle von Registern speichert, könnte z. B. so aussehen:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi temp2, 0
sts OCR_1, temp2
ldi temp2, 1
sts OCR_2, temp2
ldi temp2, 10
sts OCR_3, temp2
ldi temp2, 20
sts OCR_4, temp2
ldi temp2, 80
sts OCR_5, temp2
ldi temp2, 127
sts OCR_6, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

; *************************************************************************
; Behandlung des Timer Overflows
;
; realisiert die PWM auf 6 Kanälen
;
; veränderte Register: keine
;
timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM-Zaehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM-Zaehler wieder auf 0

WorkPWM:
sts PWMCount, temp1 ; den PWM-Zaehler wieder speichern
ldi temp, 0b11000000 ; 0 .. LED an, 1 .. LED aus

lds temp2, OCR_1
cp temp1, temp2 ; Ist der Grenzwert für LED 1 erreicht
brlt OneOn
ori temp, $01

OneOn: lds temp2, OCR_2
cp temp1, temp2 ; Ist der Grenzwert für LED 2 erreicht
brlt TwoOn
ori temp, $02

TwoOn: lds temp2, OCR_3
cp temp1, temp2 ; Ist der Grenzwert für LED 3 erreicht
brlt ThreeOn
ori temp, $04

ThreeOn:lds temp2, OCR_4
cp temp1, temp2 ; Ist der Grenzwert für LED 4 erreicht
brlt FourOn
ori temp, $08

FourOn: lds temp2, OCR_5
cp temp1, temp2 ; Ist der Grenzwert für LED 5 erreicht
brlt FiveOn
ori temp, $10

FiveOn: lds temp2, OCR_6
cp temp1, temp2 ; Ist der Grenzwert für LED 6 erreicht
brlt SetBits
ori temp, $20

SetBits: ; Die neue Bitbelegung am Port ausgeben
out PORTB, temp

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop temp2
pop temp1
pop temp

reti
;
; **********************************************
;
.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; Der PWM-Counter (0 bis 127)
OCR_1: .BYTE 1 ; 6 Bytes für die OCR-Register
OCR_2: .BYTE 1
OCR_3: .BYTE 1
OCR_4: .BYTE 1
OCR_5: .BYTE 1
OCR_6: .BYTE 1
</syntaxhighlight>

==Spezielle Register==
===Der Z-Pointer (R30 und R31)===
Das Registerpärchen '''R30''' und '''R31''' kann zu einem einzigen logischen Register zusammengefasst werden und heisst dann '''Z-Pointer'''. Diesem kann eine spezielle Aufgabe zukommen, indem er als Adressangabe fungieren kann, von welcher Speicherzelle im SRAM ein Ladevorgang (bzw. Speichervorgang) durchgeführt werden soll. Anstatt die Speicheradresse wie beim '''LDS''' bzw. '''STS''' direkt im Programmcode anzugeben, kann diese Speicheradresse zunächst in den '''Z-Pointer''' geladen werden und der Lesevorgang (Schreibvorgang) über diesen '''Z-Pointer''' abgewickelt werden. Dadurch wird aber die '''SRAM'''-Speicheradresse berechenbar, denn natürlich kann mit den Registern '''R30''' und '''R31''', wie mit den anderen Registern auch, Arithmetik betrieben werden. Besonders komfortabel ist dies, da im Ladebefehl noch zusätzliche Manipulationen angegeben werden können, die oft benötigte arithmetische Operationen implementieren.

===LD===

* '''LD rxx, Z'''
* '''LD rxx, Z+'''
* '''LD rxx, -Z'''

Lädt das Register '''rxx''' mit dem Inhalt der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===LDD===
* '''LDD rxx, Z+q'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Ladeanweisung

<syntaxhighlight lang="avrasm">
LDD r18, Z + $28
</syntaxhighlight>

der Inhalt der Speicherzellen $1000 + $28 = $1028 in das Register r18 geladen.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===ST===

* '''ST Z, rxx'''
* '''ST Z+, rxx'''
* '''ST -Z, rxx'''

Speichert den Inhalt des Register '''rxx''' in der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===STD===
* '''STD Z+q, rxx'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Speicheranweisung
<syntaxhighlight lang="avrasm">
STD Z + $28, r18
</syntaxhighlight>

der Inhalt des Registers r18 in der Speicherzellen $1000 + $28 = $1028 gespeichert.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===Beispiel===

Durch Verwendung des '''Z-Pointers''' ist es möglich die Interrupt Funktion wesentlich kürzer und vor allem ohne ständige Wiederholung von im Prinzip immer gleichem Code zu formulieren. Man stelle sich nur mal vor wie dieser Code aussehen würde, wenn anstelle von 6 PWM Stufen, deren 40 gebraucht würden. Mit dem '''Z-Pointer''' ist es möglich diesen auf das erste der OCR Bytes zu setzen und dann in einer Schleife eines nach dem anderen abzuarbeiten. Nach dem Laden des jeweiligen OCR Wertes, wird der '''Z-Pointer''' automatisch durch den '''LD'''-Befehl auf das nächste zu verarbeitende OCR Byte weitergezählt.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18
.def temp3 = r19

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)

ldi temp2, 0
st Z+, temp2
ldi temp2, 1
st Z+, temp2
ldi temp2, 10
st Z+, temp2
ldi temp2, 20
st Z+, temp2
ldi temp2, 80
st Z+, temp2
ldi temp2, 127
st Z+, temp2

ldi temp2, 0 ; den PWM Counter auf 0 setzen
sts PWMCount, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

timer0_overflow: ; Timer 0 Overflow Handler
lds temp1, PWMCount ; den PWM ZAehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM Zaehler auf 0 setzen

WorkPWM:
sts PWMCount, temp1 ; den PWM Zaehler wieder speichern

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)
ldi temp3, $01 ; das Bitmuster für PWM Nr. i
ldi temp, 0b11000000 ; 0 .. Led an, 1 .. Led aus

pwmloop:
ld temp2, Z+ ; den OCR Wert für PWM Nr. i holen und Z-Pointer erhöhen
cp temp1, temp2 ; ist der Grenzwert für PWM Nr. i erreicht?
brlo LedOn
or temp, temp3
LedOn:
lsl temp3 ; das Bitmuster schieben
cpi temp3, $40 ; alle Bits behandelt ?
brne pwmloop ; nächster Schleifendurchlauf

out PORTB, temp ; Die neue Bitbelegung am Port ausgeben
reti

.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; der PWM Zaehler (0 bis 127)
OCR: .BYTE 6 ; 6 Bytes für die OCR Register

</syntaxhighlight>

===X-Pointer, Y-Pointer===
Neben dem '''Z-Pointer''' gibt es noch den '''X-Pointer''' bzw. '''Y-Pointer'''. Sie werden gebildet von den Registerpärchen
* '''X-Pointer''': r26, r27
* '''Y-Pointer''': r28, r29
* '''Z-Pointer''': r30, r31
Alles über den '''Z-Pointer''' gesagte gilt sinngemäß auch für den '''X-Pointer''' bzw. '''Y-Pointer''' mit einer Ausnahme: Mit dem '''X-Pointer''' ist kein Zugriff '''LDD'''/'''STD''' mit einem Displacement möglich.

== Siehe auch ==
* [[Adressierung]]

----

{{Navigation_zurückhochvor|
zurücktext=Schieberegister|
zurücklink=AVR-Tutorial: Schieberegister|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=7-Segment-Anzeige|
vorlink=AVR-Tutorial: 7-Segment-Anzeige}}

[[Category:AVR-Tutorial|SRAM]]

AVR-Tutorial: SRAM

2013-09-09T07:48:48Z

Kbuchegg: /* Beispiel */

==SRAM - Der Speicher des Controllers==

Nachdem in einem der vorangegangenen Kapitel eine [[AVR-Tutorial:_PWM|Software-PWM]] vorgestellt und in einem weiteren Kapitel darüber gesprochen wurde, wie man mit [[AVR-Tutorial:_Schieberegister|Schieberegistern]] die Anzahl an I/O-Pins erhöhen kann, wäre es naheliegend, beides zu kombinieren und den ATmega8 mal 20 oder 30 LEDs ansteuern zu lassen. Wenn es da nicht ein Problem gäbe: die Software-PWM hält ihre Daten in Registern, so wie das praktisch alle Programme bisher machten. Während allerdings 6 PWM-Kanäle noch problemlos in den Registern untergebracht werden konnten, ist dies mit 30 oder noch mehr PWM-Kanälen nicht mehr möglich. Es gibt schlicht und ergreifend nicht genug Register.

Es gibt aber einen Ausweg. Der ATmega8 verfügt über 1kByte '''SRAM''' (statisches RAM). Dieses RAM wurde bereits indirekt durch den '''Stack''' benutzt. Bei jedem Aufruf eines Unterprogrammes, sei es über einen expliziten '''CALL''' (bzw. '''RCALL''') oder einen Interrupt, wird die Rücksprungadresse irgendwo gespeichert. Dies geschieht genau in diesem SRAM. Auch '''PUSH''' und '''POP''' operieren in diesem Speicher.

Ein Programm darf Speicherzellen im '''SRAM''' direkt benutzen und dort Werte speichern bzw. von dort Werte einlesen. Es muss nur darauf geachtet werden, dass es zu keiner Kollision mit dem Stack kommt, in dem z. B. die erwähnten Rücksprungadressen für Unterprogramme gespeichert werden. Da viele Programme aber lediglich ein paar Byte '''SRAM''' brauchen, der Rücksprungstack von der oberen Grenze des '''SRAM''' nach unten wächst und der ATmega8 immerhin über '''1kByte''' '''SRAM''' verfügt, ist dies in der Praxis kein all zu großes Problem.

==Das .DSEG und .BYTE==
Um dem Assembler mitzuteilen, dass sich der folgende Abschnitt auf das SRAM bezieht, gibt es die Direktive '''.DSEG''' (Data Segment). Alle nach einer '''.DSEG''' Direktive folgenden Speicherreservierungen werden vom Assembler im SRAM durchgeführt.

Die Direktive '''.BYTE''' stellt dabei eine derartige Speicherreservierung dar. Es ermöglicht, der Speicherreservierung einen Namen zu geben und es erlaubt auch, nicht nur 1 Byte sondern eine ganze Reihe von Bytes unter einem Namen zu reservieren.

<syntaxhighlight lang="avrasm">
.DSEG ; Umschalten auf das SRAM Datensegment
Counter: .BYTE 1 ; 1 Byte unter dem Namen 'Counter' reservieren
Test: .BYTE 20 ; 20 Byte unter dem Namen 'Test' reservieren
</syntaxhighlight>

==spezielle Befehle==
Für den Zugriff auf den '''SRAM'''-Speicher gibt es spezielle Befehle. Diese holen entweder den momentanen Inhalt einer Speicherzelle und legen ihn in einem Register ab oder legen den Inhalt eines Registers in einer '''SRAM'''-Speicherzelle ab.

===LDS===
Liest die angegebene '''SRAM'''-Speicherzelle und legt den gelesenen Wert in einem Register ab.

<syntaxhighlight lang="avrasm">
LDS r17, Counter ; liest die Speicherzelle mit dem Namen 'Counter'
; und legt den gelesenen Wert im Register r17 ab
</syntaxhighlight>

===STS===
Legt den in einem Register gespeicherten Wert in einer '''SRAM'''-Speicherzelle ab.

<syntaxhighlight lang="avrasm">
STS Counter, r17 ; Speichert den Inhalt von r17 in der
; Speicherzelle 'Counter'
</syntaxhighlight>

===Beispiel===

Eine mögliche Implementierung der [[AVR-Tutorial:_PWM|Software-PWM]], die den PWM-Zähler sowie die einzelnen OCR-Grenzwerte im '''SRAM''' anstelle von Registern speichert, könnte z. B. so aussehen:

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi temp2, 0
sts OCR_1, temp2
ldi temp2, 1
sts OCR_2, temp2
ldi temp2, 10
sts OCR_3, temp2
ldi temp2, 20
sts OCR_4, temp2
ldi temp2, 80
sts OCR_5, temp2
ldi temp2, 127
sts OCR_6, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

timer0_overflow: ; Timer 0 Overflow Handler
push temp ; Alle verwendeten Register sichern
push temp1
push temp2
in temp, SREG
push temp

lds temp1, PWMCount ; den PWM-Zaehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM-Zaehler wieder auf 0

WorkPWM:
sts PWMCount, temp1 ; den PWM-Zaehler wieder speichern
ldi temp, 0b11000000 ; 0 .. LED an, 1 .. LED aus

lds temp2, OCR_1
cp temp1, temp2 ; Ist der Grenzwert für LED 1 erreicht
brlt OneOn
ori temp, $01

OneOn: lds temp2, OCR_2
cp temp1, temp2 ; Ist der Grenzwert für LED 2 erreicht
brlt TwoOn
ori temp, $02

TwoOn: lds temp2, OCR_3
cp temp1, temp2 ; Ist der Grenzwert für LED 3 erreicht
brlt ThreeOn
ori temp, $04

ThreeOn:lds temp2, OCR_4
cp temp1, temp2 ; Ist der Grenzwert für LED 4 erreicht
brlt FourOn
ori temp, $08

FourOn: lds temp2, OCR_5
cp temp1, temp2 ; Ist der Grenzwert für LED 5 erreicht
brlt FiveOn
ori temp, $10

FiveOn: lds temp2, OCR_6
cp temp1, temp2 ; Ist der Grenzwert für LED 6 erreicht
brlt SetBits
ori temp, $20

SetBits: ; Die neue Bitbelegung am Port ausgeben
out PORTB, temp

pop temp ; die gesicherten Register wiederherstellen
out SREG, temp
pop temp2
pop temp1
pop temp

reti

.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; Der PWM-Counter (0 bis 127)
OCR_1: .BYTE 1 ; 6 Bytes für die OCR-Register
OCR_2: .BYTE 1
OCR_3: .BYTE 1
OCR_4: .BYTE 1
OCR_5: .BYTE 1
OCR_6: .BYTE 1
</syntaxhighlight>

==Spezielle Register==
===Der Z-Pointer (R30 und R31)===
Das Registerpärchen '''R30''' und '''R31''' kann zu einem einzigen logischen Register zusammengefasst werden und heisst dann '''Z-Pointer'''. Diesem kann eine spezielle Aufgabe zukommen, indem er als Adressangabe fungieren kann, von welcher Speicherzelle im SRAM ein Ladevorgang (bzw. Speichervorgang) durchgeführt werden soll. Anstatt die Speicheradresse wie beim '''LDS''' bzw. '''STS''' direkt im Programmcode anzugeben, kann diese Speicheradresse zunächst in den '''Z-Pointer''' geladen werden und der Lesevorgang (Schreibvorgang) über diesen '''Z-Pointer''' abgewickelt werden. Dadurch wird aber die '''SRAM'''-Speicheradresse berechenbar, denn natürlich kann mit den Registern '''R30''' und '''R31''', wie mit den anderen Registern auch, Arithmetik betrieben werden. Besonders komfortabel ist dies, da im Ladebefehl noch zusätzliche Manipulationen angegeben werden können, die oft benötigte arithmetische Operationen implementieren.

===LD===

* '''LD rxx, Z'''
* '''LD rxx, Z+'''
* '''LD rxx, -Z'''

Lädt das Register '''rxx''' mit dem Inhalt der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===LDD===
* '''LDD rxx, Z+q'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Ladeanweisung

<syntaxhighlight lang="avrasm">
LDD r18, Z + $28
</syntaxhighlight>

der Inhalt der Speicherzellen $1000 + $28 = $1028 in das Register r18 geladen.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===ST===

* '''ST Z, rxx'''
* '''ST Z+, rxx'''
* '''ST -Z, rxx'''

Speichert den Inhalt des Register '''rxx''' in der Speicherzelle, deren Adresse im '''Z-Pointer''' angegeben ist. Bei den Varianten mit '''Z+''' bzw. '''-Z''' wird zusätzlich der '''Z-Pointer''' '''''nach''''' der Operation um 1 erhöht bzw. '''''vor''''' der Operation um 1 vermindert.

===STD===
* '''STD Z+q, rxx'''

Hier erfolgt der Zugriff wieder über den '''Z-Pointer''' wobei vor dem Zugriff zur Adressangabe im '''Z-Pointer''' noch das Displacement '''q''' addiert wird.

Enthält also der '''Z-Pointer''' die Adresse $1000 und sei '''q''' der Wert $28, so wird mit einer Speicheranweisung
<syntaxhighlight lang="avrasm">
STD Z + $28, r18
</syntaxhighlight>

der Inhalt des Registers r18 in der Speicherzellen $1000 + $28 = $1028 gespeichert.

Der Wertebereich für '''q''' erstreckt sich von 0 bis 63.

===Beispiel===

Durch Verwendung des '''Z-Pointers''' ist es möglich die Interrupt Funktion wesentlich kürzer und vor allem ohne ständige Wiederholung von im Prinzip immer gleichem Code zu formulieren. Man stelle sich nur mal vor wie dieser Code aussehen würde, wenn anstelle von 6 PWM Stufen, deren 40 gebraucht würden. Mit dem '''Z-Pointer''' ist es möglich diesen auf das erste der OCR Bytes zu setzen und dann in einer Schleife eines nach dem anderen abzuarbeiten. Nach dem Laden des jeweiligen OCR Wertes, wird der '''Z-Pointer''' automatisch durch den '''LD'''-Befehl auf das nächste zu verarbeitende OCR Byte weitergezählt.

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18
.def temp3 = r19

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp timer0_overflow ; Timer Overflow Handler

main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp

ldi temp, 0xFF ; Port B auf Ausgang
out DDRB, temp

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)

ldi temp2, 0
st Z+, temp2
ldi temp2, 1
st Z+, temp2
ldi temp2, 10
st Z+, temp2
ldi temp2, 20
st Z+, temp2
ldi temp2, 80
st Z+, temp2
ldi temp2, 127
st Z+, temp2

ldi temp2, 0 ; den PWM Counter auf 0 setzen
sts PWMCount, temp2

ldi temp, (1<<CS00) ; CS00 setzen: Teiler 1
out TCCR0, temp

ldi temp, (1<<TOIE0) ; TOIE0: Interrupt bei Timer Overflow
out TIMSK, temp

sei

loop: rjmp loop

timer0_overflow: ; Timer 0 Overflow Handler
lds temp1, PWMCount ; den PWM ZAehler aus dem Speicher holen
inc temp1 ; Zaehler erhoehen
cpi temp1, 128 ; wurde 128 erreicht ?
brne WorkPWM ; Nein
clr temp1 ; Ja: PWM Zaehler auf 0 setzen

WorkPWM:
sts PWMCount, temp1 ; den PWM Zaehler wieder speichern

ldi r30,LOW(OCR) ; den Z-Pointer mit dem Start der OCR Bytes laden
ldi r31,HIGH(OCR)
ldi temp3, $01 ; das Bitmuster für PWM Nr. i
ldi temp, 0b11000000 ; 0 .. Led an, 1 .. Led aus

pwmloop:
ld temp2, Z+ ; den OCR Wert für PWM Nr. i holen und Z-Pointer erhöhen
cp temp1, temp2 ; ist der Grenzwert für PWM Nr. i erreicht?
brlo LedOn
or temp, temp3
LedOn:
lsl temp3 ; das Bitmuster schieben
cpi temp3, $40 ; alle Bits behandelt ?
brne pwmloop ; nächster Schleifendurchlauf

out PORTB, temp ; Die neue Bitbelegung am Port ausgeben
reti

.DSEG ; das Folgende kommt ins SRAM

PWMCount: .BYTE 1 ; der PWM Zaehler (0 bis 127)
OCR: .BYTE 6 ; 6 Bytes für die OCR Register

</syntaxhighlight>

===X-Pointer, Y-Pointer===
Neben dem '''Z-Pointer''' gibt es noch den '''X-Pointer''' bzw. '''Y-Pointer'''. Sie werden gebildet von den Registerpärchen
* '''X-Pointer''': r26, r27
* '''Y-Pointer''': r28, r29
* '''Z-Pointer''': r30, r31
Alles über den '''Z-Pointer''' gesagte gilt sinngemäß auch für den '''X-Pointer''' bzw. '''Y-Pointer''' mit einer Ausnahme: Mit dem '''X-Pointer''' ist kein Zugriff '''LDD'''/'''STD''' mit einem Displacement möglich.

== Siehe auch ==
* [[Adressierung]]

----

{{Navigation_zurückhochvor|
zurücktext=Schieberegister|
zurücklink=AVR-Tutorial: Schieberegister|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=7-Segment-Anzeige|
vorlink=AVR-Tutorial: 7-Segment-Anzeige}}

[[Category:AVR-Tutorial|SRAM]]

Diskussion:AVR-Tutorial: 7-Segment-Anzeige

2013-07-30T19:33:25Z

Kbuchegg: /* 8fach Latches bzw D Flip-Flop erwähnen */

Das Programm zur Multiplexanzeige paßt nicht zur oben abgebildeten Schaltung:
Die Digits werden mit dem Pegel Low eingeschaltet. Im Programm wird High benutzt.

----

Die Konstanten im Programm sind so gewählt dass 0 (low) für ein aktives Segment steht, das müsste also stimmen.
-[[Benutzer:Andreas|andreas]] 20:04, 18. Okt 2007 (CEST)

----

Die Segmente sind schon O.K., ich meine aber die Digits an PC0 - PC3.
Die sind auch low-aktiv, werden im Prog aber als high-aktiv behandelt. Deshalb wird nur "Mist" angezeigt, weil 3 Digits zur selben Zeit angesteuert werden.
--[[Benutzer:Wibwato|thomas]] 12:45, 7. Dez 2007 (CET)

----

Da scheint tatsächlich ein Bug zu sein. Das AUSschalten aller vier PNP-Transistoren vor dem ANschalten der jeweiligen Ziffer im Multiplex ist wohl falsch: http://www.mikrocontroller.net/topic/134185
[[Benutzer:Stefan|Stefan]] 14:36, 6. Apr. 2009 (CEST)

== 8fach Latches bzw D Flip-Flop erwähnen ==

Was haltet ihr davon, wenn man in diesem Tutorial noch kurz Latches bzw D Flip-Flops erwähnt, die man zwischen µC und 7Segmentanzeigen schalten kann. Somit wären dann eine viel langsamere Ansteuerung möglich. Denke da zB an 74HCT573 bzw 574, da diese gleich 8 Signale puffern können.

Klar geht es auch so, aber manchmal sucht man vielleicht gerade nach dieser Möglichkeit und kommt dann im Tutorial vorbei. Denke, dass es auch nicht schadet, wenn Anfänger neben den Schieberegistern hier den parallelen "Partner" sehen.

Wie steht ihr hierzu?

Gruß

----

Wieso kann man langsamer multiplexen mit Latches? Das ist ein Irrtum. Ausserdem verwirrt es Anfänger mehr als es ihnen hilft. Porterweiterung per Schieberegister oder Latches ist ein anders Thema und darum auch in einem anderen Tutorial.

MFG
Falk

== Anewndungsbeispiel ==
Ich hab den im November 2012 eingefügten Link zu einem Anwendungsbeispiel wieder entfernt. Zum einen ist das ein C-Programm und hat als solches in einem Assembler-Tutorial IMHO nicht wirklich etwas verloren. Zum anderen zeigt dieses Anwendungsbeispiel Multiplexing genau so, wie man es nicht macht: mit Schleifenkonstrukten und Delays innerhalb der Schleife.

AVR-Tutorial: 7-Segment-Anzeige

2013-07-30T19:27:53Z

Kbuchegg: /* Anwendungsbeispiele */

Die Ausgabe von Zahlenwerten auf ein Text-LCD ist sicherlich das Nonplusultra, aber manchmal liegen die Dinge sehr viel einfacher. Um beispielsweise eine Temperatur anzuzeigen ist ein LCD etwas Overkill. In solchen Fällen kann die Ausgabe auf ein paar 7-Segmentanzeigen gemacht werden. Ausserdem haben 7-Segmentanzeigen einen ganz besonderen Charme :-)

==Typen von 7-Segment Anzeigen==

Eine einzelne 7-Segmentanzeige besteht aus sieben (mit Dezimalpunkt acht) einzelnen [[LED]]s in einem gemeinsamen Gehäuse. Aus praktischen Gründen wird einer der beiden Anschlüsse jeder LED mit den gleichen Anschlüssen der anderen LED verbunden und gemeinsam aus dem Gehäuse herausgeführt. Das spart Pins am Gehäuse und später bei der Ansteuerung. Dementsprechend spricht man von Anzeigen mit ''gemeinsamer Anode'' (engl. common anode) bzw. ''gemeinsamer Kathode'' (engl. common cathode).

[[Bild:Tut_7_Seg_00.gif | framed | center | Interne Verschaltung der 7-Segmentanzeigen]]
 

==Eine einzelne 7-Segment Anzeige==

===Schaltung===

[[Bild:Tut_7_Seg_02.gif | thumb| left | 80px| Pin- belegung einer 7-Segment- anzeige]]

[[Bild:Tut_7_Seg_01.gif | thumb | right |240px| Ansteuerung einer einzelnen 7-Segmentanzeige]]

Eine einzelne 7-Segmentanzeige wird nach dem folgenden Schema am '''Port D''' des Mega8 angeschlossen. Port D wurde deshalb gewählt, da er am Mega8 als einziger Port aus den vollen 8 Bit besteht. Die 7-Segmentanzeige hat neben den Segmenten '''a''' bis '''g''' eine gemeinsame Anode '''CA''' sowie einen Dezimalpunkt '''dp''' (siehe Bild).

Welcher Pin an der Anzeige welchem Segment (a-g) bzw. dem Dezimalpunkt entspricht wird am besten dem Datenblatt zur Anzeige entnommen. Hat man kein Datenblatt dann kann man auch empirisch die Pinbelegung feststellen, indem man mit einer 5V Quelle und einem 1k Widerstand einfach probweise alle Pins 'abklappert'. 1k deswegen, damit man im Zweifellsfall Low-Current LED nicht überfordert. Eine 7-Segment Anzeige, die auf die üblichen 10 bis 20mA ausgelegt ist, wird damit immer noch leuchten, wenn auch schwach. Aber mehr braucht es ja auch nicht um die Pinbelegung feststellen zu können. Im Folgenden wird von dieser Segmentbelegung ausgegangen:

Wird eine andere Belegung genutzt dann ist das prinzipiell möglich, jedoch müsste das in der Programmierung berücksichtigt werden.

Da eine 7-Segmentanzeige konzeptionell sieben einzelnen LEDs entspricht, ergibt sich im Prinzip keine Änderung in der Ansteuerung einer derartigen Anzeige im Vergleich zur LED Ansteuerung wie sie im [[AVR-Tutorial: IO-Grundlagen]] gezeigt wird. Genau wie bei den einzelnen LEDs wird eine davon eingeschaltet, indem der zugehörige Port Pin auf 0 gesetzt wird. Aber anders als bei einzelnen LED möchte man mit einer derartigen Anzeige eine Ziffernanzeige erhalten. Dazu ist es lediglich notwendig, für eine bestimmte Ziffer die richtigen LEDs einzuschalten.

{{Clear}}

===Codetabelle===

[[Bild:Tut_7_Seg_02a.gif | right | thumb | 80px | Darstellung der Ziffer "3"]]
Die Umkodierung von einzelnen Ziffern in ein bestimmtes Ausgabemuster kann über eine sog. Codetabelle geschehen: Die auszugebende Ziffer wird als Offset zum Anfang dieser Tabelle aufgefasst und aus der Tabelle erhält man ein Byte (Code), welches direkt auf den Port ausgegeben werden kann und das entsprechende Bitmuster enthält, sodass die für diese Ziffer notwendigen LED ein- bzw. ausgeschaltet sind.

;Beispiel: Um die Ziffer '''3''' anzuzeigen, müssen auf der Anzeige die Segmente '''a''', '''b''', '''c''', '''d''' und '''g''' aufleuchten. Alle anderen Segmente sollen dunkel sein.

Aus dem Anschlußschema ergibt sich, dass die dazu notwendige Ausgabe am Port binär '''10110000''' lauten muss. Untersucht man dies für alle Ziffern, so ergibt sich folgende Tabelle:
<syntaxhighlight lang="avrasm">
.db 0b11000000 ; 0: a, b, c, d, e, f
.db 0b11111001 ; 1: b, c
.db 0b10100100 ; 2: a, b, d, e, g
.db 0b10110000 ; 3: a, b, c, d, g
.db 0b10011001 ; 4: b, c, f, g
.db 0b10010010 ; 5: a, c, d, f, g
.db 0b10000010 ; 6: a, c, d, e, f, g
.db 0b11111000 ; 7: a, b, c
.db 0b10000000 ; 8: a, b, c, d, e, f, g
.db 0b10010000 ; 9: a, b, c, d, f, g
</syntaxhighlight>

===Programm===

Das Testprogramm stellt nacheinander die Ziffern 0 bis 9 auf der 7-Segmentanzeige dar. Die jeweils auszugebende Zahl steht im Register '''count''' und wird innerhalb der Schleife um jeweils 1 erhöht. Hat das Register den Wert 10 erreicht, so wird es wieder auf 0 zurückgesetzt. Nach der Erhöhung folgt eine Warteschleife, welche dafür sorgt, dass bis zur nächsten Ausgabe eine gewisse Zeit vergeht. Normalerweise macht man keine derartigen langen Warteschleifen, aber hier geht es ja nicht ums Warten sondern um die Ansteuerung einer 7-Segmentanzeige. Einen Timer dafür zu benutzen wäre zunächst zuviel Aufwand.

Die eigentliche Ausgabe und damit der in diesem Artikel interessante Teil findet jedoch direkt nach dem Label loop statt. Die bereits bekannte Codetabelle wird mittels '''.db''' Direktive ('''d'''efine '''b'''yte) in den [[Speicher#Flash-ROM | Flash-Speicher]] gelegt. Der Zugriff darauf erfolgt über den Z-Pointer und dem Befehl '''lpm'''. Zusätzlich wird vor dem Zugriff noch der Wert des Registers '''count''' und damit der aktuelle Zählerwert zum Z-Pointer addiert.

Beachtet werden muss nur, dass der Zählerwert verdoppelt werden muss. Dies hat folgenden Grund: Wird die Tabelle so wie hier gezeigt mittels einzelnen '''.db''' Anweisungen aufgebaut, so fügt der Assembler sog. '''Padding Bytes''' zwischen die einzelnen Bytes ein, damit jede '''.db''' Anweisung auf einer geraden Speicheradresse liegt. Dies ist eine direkte Folge der Tatsache, dass der Flash-Speicher '''wortweise''' (16 Bit) und nicht '''byteweise''' (8 Bit) organisiert ist. Da aber von einem .db in der Tabelle zum nächsten .db eine Differenz von 2 Bytes vorliegt, muss dies in der Berechnung berücksichtigt werden. Im zweiten Beispiel auf dieser Seite wird dies anders gemacht. Dort wird gezeigt wie man durch eine andere Schreibweise der Tabelle das Erzeugen der Padding Bytes durch den Assembler verhindern kann.

Aus dem gleichen Grund wird auch der Z-Pointer mit dem 2-fachen der Startadresse der Tabelle geladen. Die Startadresse wird vom Assembler in wortweiser Adressierung eingesetzt, '''lpm''' möchte die Zugriffsadresse als Byteadresse angegeben haben.

Interessant ist auch, dass in der Berechnung ein Register benötigt wird, welches den Wert 0 enthält. Dies deshalb, da es im AVR keinen Befehl gibt der eine Konstante mit gleichzeitiger Berücksichtigung des Carry-Bits addieren kann. Daher muss diese Konstante zunächst in ein Register geladen werden und erst dann kann die Addition mithilfe dieses Registers vorgenommen werden. Das Interessante daran ist nun, dass dieser Umstand in sehr vielen Programmen vorkommt und es sich bei der Konstanten in der überwiegenden Mehrzahl der Fälle um die Konstante 0 handelt. Viele Programmierer reservieren daher von vorne herein ein Register für diesen Zweck und nennen es das Zero-Register. Sinnvollerweise legt man dieses Register in den Bereich r0..r15, da diese Register etwas zweitklassig sind (ldi, cpi etc. funktionieren nicht damit).

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def zero = r1
.def count = r16
.def temp1 = r17

.org 0x0000
rjmp main ; Reset Handler
;
main:
ldi temp1, HIGH(RAMEND)
out SPH, temp1
ldi temp1, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp1

;
ldi temp1, $FF ; die Anzeige hängt am Port D
out DDRD, temp1 ; alle Pins auf Ausgang
;
ldi count, 0 ; und den Zähler initialisieren
mov zero, count
;
loop:
ldi ZL, LOW(Codes*2) ; die Startadresse der Tabelle in den
ldi ZH, HIGH(Codes*2) ; Z-Pointer laden

mov temp1, count ; die wortweise Adressierung der Tabelle
add temp1, count ; berücksichtigen

add ZL, temp1 ; und ausgehend vom Tabellenanfang
adc ZH, zero ; die Adresse des Code Bytes berechnen

lpm ; dieses Code Byte in das Register r0 laden

out PORTD, r0 ; und an die Anzeige ausgeben
;
inc count ; den Zähler erhöhen, wobei der Zähler
cpi count, 10 ; immer nur von 0 bis 9 zählen soll
brne wait
ldi count, 0
;
wait: ldi r17, 10 ; und etwas warten, damit die Ziffer auf
wait0: ldi r18, 0 ; der Anzeige auch lesbar ist, bevor die
wait1: ldi r19, 0 ; nächste Ziffer gezeigt wird
wait2: dec r19
brne wait2
dec r18
brne wait1
dec r17
brne wait0
;
rjmp loop ; auf zur nächsten Ausgabe
;
Codes: ; Die Codetabelle für die Ziffern 0 bis 9
; sie regelt, welche Segmente für eine bestimmte
; Ziffer eingeschaltet werden müssen
;
.db 0b11000000 ; 0: a, b, c, d, e, f
.db 0b11111001 ; 1: b, c
.db 0b10100100 ; 2: a, b, d, e, g
.db 0b10110000 ; 3: a, b, c, d, g
.db 0b10011001 ; 4: b, c, f, g
.db 0b10010010 ; 5: a, c, d, f, g
.db 0b10000010 ; 6: a, c, d, e, f, g
.db 0b11111000 ; 7: a, b, c
.db 0b10000000 ; 8: a, b, c, d, e, f, g
.db 0b10010000 ; 9: a, b, c, d, f, g

</syntaxhighlight>

==Mehrere 7-Segment Anzeigen (Multiplexen)==

Mit dem bisherigen Vorwissen könnte man sich jetzt daran machen, auch einmal drei oder vier Anzeigen mit dem Mega8 anzusteuern. Leider gibt es da ein Problem, denn für eine Anzeige sind acht Portpins notwendig - vier Anzeigen würden demnach 32 Portpins benötigen. Die hat der Mega8 aber nicht. Dafür gibt es aber mehrere Auswege. Schieberegister sind bereits in einem anderen [[AVR-Tutorial:_Schieberegister|Tutorial]] beschrieben. Damit könnte man sich ganz leicht die benötigten 32 Ausgangsleitungen mit nur 3 Portpins erzeugen. Das Prinzip der Ansteuerung unterscheidet sich in nichts von der Ansteurung einer einzelnen 7-Segment Anzeige, lediglich die Art und Weise, wie die 'Ausgangspins' zu ihren Werten kommen ist anders und durch die Verwendung von Schieberegistern vorgegeben. An dieser Stelle soll aber eine andere Variante der Ansteuerung gezeigt werden. Im Folgenden werden wir uns daher das [[Multiplexen]] einmal näher ansehen.

Multiplexen bedeutet, dass nicht alle vier Anzeigen gleichzeitig eingeschaltet sind, sondern immer nur Eine für eine kurze Zeit. Geschieht der Wechsel zwischen den Anzeigen schneller als wir Menschen das wahrnehmen können, so erscheinen uns alle vier Anzeigen gleichzeitig in Betrieb zu sein obwohl immer nur Eine für eine kurze Zeit aufleuchtet. Dabei handelt es sich praktisch um einen Sonderfall einer [[LED-Matrix]] mit nur einer Zeile. Die vier Anzeigen können sich dadurch die einzelnen Segmentleitungen teilen und alles was benötigt wird sind 4 zusätzliche Steuerleitungen für die 4 Anzeigen, mit denen jeweils eine Anzeige eingeschaltet wird. Dieses Ein/Ausschalten wird mit einem pnp-Transistor in der Versorgungsspannung jeder Anzeige realisiert, die vom Mega8 am '''PortC''' angesteuert werden.

Ein Aspekt dieser Ansteuerungsart ist die Multiplexfrequenz, also ein kompletter Zyklus das Weiterschaltens von einer Anzeige zur nächsten . Sie muss hoch genug sein, um ein Flimmern der Anzeige zu vermeiden. Das menschliche Auge ist träge, im Kino reichen 24 Bilder pro Sekunde, beim Fernseher sind es 50. Um auf der sicheren Seite zu sein, dass auch Standbilder ruhig wirken, sollen jedes Segment mit mindestens 100 Hz angesteuert werden, es also mindestens alle 10ms angeschaltet ist. In Ausnahmefällen können aber selbst 100 Hz noch flimmern, z. B. wenn die Anzeige schnell bewegt wird oder wenn es zu Interferenzerscheinungen mit künstlichen Lichtquellen kommt, die mit Wechselstrom betrieben werden.

[[Bild:Tut_7_Seg_03.gif | thumb|right|280px | Ansteuerung von vier 7-Segmentanzeigen per Zeit-Multiplex]]
Bei genauerer Betrachtung fällt auch auf, dass die vier Anzeigen nicht mehr ganz so hell leuchten wie die eine einzelne Anzeige ohne Multiplexen. Bei wenigen Anzeigen ist dies praktisch kaum sichtbar, erst bei mehreren Anzeigen wird es deutlich. Um dem entgegen zu wirken lässt man pro Segment einfach mehr Strom fließen, bei LEDs dürfen dann 20mA überschritten werden. Als Faustregel gilt, dass der n-fache Strom für die (1/n)-fache Zeit fließen darf. Details finden sich im Datenblatt unter dem Punkt '''Peak-Current''' (Spitzenstrom) und '''Duty-Cycle''' ([[PWM|Tastverhältnis]]).

Allerdings gibt es noch ein anderes Problem wenn insgesamt zu viele Anzeigen gemultiplext werden. Die Pulsströme durch die LEDs werden einfach zu hoch. Die meisten LEDs kann man bis 8:1 multiplexen, manchmal auch bis 16:1. Hier fliesst aber schon ein Pulsstrom von 320mA (16 x 20mA), was nicht mehr ganz ungefährlich ist. '''Strom lässt sich durch Multiplexen nicht sparen''', denn die verbrauchte Leistung ändert sich beim n-fachen Strom für 1/n der Zeit nicht. Kritisch wird es aber, wenn das Multiplexen deaktiviert wird (Ausfall der Ansteuerung durch Hardware- oder Softwarefehler) und der n-fache Strom dauerhaft durch eine Segment-LED fließt. Bei 320mA werden die meisten LEDs innerhalb von Sekunden zerstört. Hier muss sichergestellt werden, dass sowohl Programm (Breakpoint im Debugger) als auch Schaltung (Reset, Power-On, [http://www.mikrocontroller.net/topic/107941]) diesen Fall verhindern. Prinzipiell sollte man immer den Pulsstrom und die Multiplexfrequenz einmal überschlagen, bevor der Lötkolben angeworfen wird.

Sollten die Anzeigen zu schwach leuchten so können, wie bereits beschrieben, die Ströme durch die Anzeigen erhöht werden. Dazu werden die 330Ω Widerstände kleiner gemacht. Da hier 4 Anzeigen gemultiplext werden, würden sich Widerstände in der Größenordnung von 100Ω anbieten. Auch muss dann der Basiswiderstand der Transistoren verkleinert werden. Auch muss berücksichtigt werden, dass der Mega8 in Summe an seinen Portpins und an den Versorgungsleitungen nicht beliebig viel Strom liefern oder abführen kann. Auch hier ist daher wieder ein Blick ins Datenblatt angebracht und gegebenenfalls muss wieder ein Transistor als Verstärker eingesetzt werden (oder eben fertige Treiberstufen in IC-Form).

===Programm===

Das folgende Programm zeigt eine Möglichkeit zum Multiplexen. Dazu wird ein Timer benutzt, der in regelmässigen Zeitabständen einen Overflow [[Interrupt]] auslöst. Innerhalb der Overflow Interrupt Routine wird
* die momentan erleuchtete Anzeige abgeschaltet
* das Muster für die nächste Anzeige am Port D ausgegeben
* die nächste Anzeige durch eine entsprechende Ausgabe am Port C eingeschaltet

Da Interruptfunktionen kurz sein sollten, holt die Interrupt Routine das auszugebende Muster für jede Stelle direkt aus dem SRAM, wo sie die Ausgabefunktion hinterlassen hat. Dies hat 2 Vorteile:
* Zum einen braucht die Interrupt Routine die Umrechnung einer Ziffer in das entsprechende Bitmuster nicht selbst machen
* Zum anderen ist die Anzeigefunktion dadurch unabhängig von dem was angezeigt wird. Die Interrupt Routine gibt das Bitmuster so aus, wie sie es aus dem SRAM liest. Werden die SRAM Zellen mit geeigneten Bitmustern gefüllt, können so auch einige Buchstaben oder Balkengrafik oder auch kleine Balken-Animationen abgespielt werden. Insbesondere letzteres sieht man manchmal bei Consumer-Geräten kurz nach dem Einschalten des Gerätes um eine Art Defektkontrolle zu ermöglichen oder einfach nur als optischer Aufputz.

Die Funktion out_number ist in einer ähnlichen Form auch schon an anderer Stelle vorgekommen: Sie verwendet die Technik der fortgesetzten Subtraktionen um eine Zahl in einzelne Ziffern zu zerlegen. Sobald jede Stelle feststeht, wird über die Codetabelle das Bitmuster aufgesucht, welches für die Interrupt Funktion an der entsprechenden Stelle im SRAM abgelegt wird.

'''Achtung''': Anders als bei der weiter oben gezeigten Variante wurde die Codetabelle ohne Padding Bytes angelegt. Dadurch ist es auch nicht notwendig derartige Padding Bytes in der Programmierung zu berücksichtigen.

Der Rest ist wieder die übliche Portinitialisierung, Timerinitialisierung und eine einfache Anwendung, indem ein 16 Bit Zähler laufend erhöht und über die Funktion out_number ausgegeben wird. Wie schon im ersten Beispiel, wurde auch hier kein Aufwand getrieben: Zähler um 1 erhöhen und mit Warteschleifen eine gewisse Verzögerungszeit einhalten. In einer realen Applikation wird man das natürlich nicht so machen, sondern ebenfalls einen Timer für diesen Teilaspekt der Aufgabenstellung einsetzen.

Weiterhin ist auch noch interessant. Die Overflow Interrupt Funktion ist wieder so ausgelegt, dass sie völlig transparent zum restlichen Programm ablaufen kann. Dies bedeutet, dass alle verwendeten Register beim Aufruf der Interrupt Funktion gesichert und beim Verlassen wiederhergestellt werden. Dadurch ist man auf der absolut sicheren Seite, hat aber den Nachteil etwas Rechenzeit für manchmal unnötige Sicherungs- und Aufräumarbeiten zu 'verschwenden'. Stehen genug freie Register zur Verfügung, dann wird man natürlich diesen Aufwand nicht treiben, sondern ein paar Register ausschließlich für die Zwecke der Behandlung der 7-Segment Anzeige abstellen und sich damit den Aufwand der Registersicherung sparen (mit Ausnahme von '''SREG''' natürlich!).

<syntaxhighlight lang="avrasm">
.include "m8def.inc"

.def temp = r16
.def temp1 = r17
.def temp2 = r18

.org 0x0000
rjmp main ; Reset Handler
.org OVF0addr
rjmp multiplex

;
;********************************************************************
; Die Multiplexfunktion
;
; Aufgabe dieser Funktion ist es, bei jedem Durchlauf eine andere Stelle
; der 7-Segmentanzeige zu aktivieren und das dort vorgesehene Muster
; auszugeben
; Die Funktion wird regelmässig in einem Timer Interrupt aufgerufen
;
; verwendet werden 6 Bytes im SRAM (siehe .DSEG weiter unten im Programm)
; NextDigit Bitmuster für die Aktivierung des nächsten Segments
; NextSegment Nummer des nächsten aktiven Segments
; Segment0 Ausgabemuster für Segment 0
; Segment1 Ausgabemuster für Segment 1
; Segment2 Ausgabemuster für Segment 2
; Segment3 Ausgabemuster für Segment 3
;
; NextSegment ist einfach nur ein Zähler, der bei jedem Aufruf der Funktion
; um 1 weitergezählt wird und bei 4 wieder auf 0 zurückgestellt wird.
; er wird benutzt, um ausgehend von der Adresse von Segment0, auf das
; jeweils als nächstes auszugebende Muster aus Segement0, Segment1,
; Segment2 oder Segment3 zuzugreifen. Die Adresse von Segment0 wird
; in den Z-Pointer geladen und NextSegment addiert.
;
; NextDigit enthält das Bitmuster, welches direkt an den Port C ausgegeben
; wird und den jeweils nächsten Transistor durchschaltet.
; Dazu enthält NextDigit am Anfang das Bitmuster 0b11111110, welches
; bei jedem Aufruf um 1 Stelle nach links verschoben wird. Beim nächsten
; Aufruf findet sich dann 0b11111101 in NextDigit, dann 0b11111011 und
; zu guter letzt 0b11110111. Wird beim nächsten Schiebevorgang 0b11101111
; erkannt, dann wird NextDigit auf 0b11111110 zurückgesetzt (und NextSegment
; auf 0) und das ganze Spiel beginnt beim nächsten Funktionsaufruf wieder
; von vorne.
;
; Segment0 .. 3 enthalten die auszugebenden Bitmuster für die Einzelleds
; der jeweiligen 7-Segment Anzeigen. Diese Muster werden so wie sie sind
; einfach ausgegeben. Soll eine der Anzeigen etwas bestimmtes anzeigen
; (zb eine Ziffer), so obliegt es dem Code, der Werte in diese SRAM
; Zellen schreibt, das dafür zuständige Bitmuster dort zu hinterlassen.
; Die Multiplexroutine kümmert sich nicht darum, dass diese Bitmuster
; in irgendeiner Art und Weise sinnvoll (oder was man dafür halten könnte)
; sind.
;
; veränderte CPU-Register: keine
;
multiplex:
push temp ; Alle verwendeten Register sichern
push temp1
in temp, SREG
push temp
push ZL
push ZH

ldi temp1, 0 ; Die 7 Segment ausschalten
out PORTC, temp1

; Das Muster für die nächste Stelle ausgeben
; Dazu zunächst mal berechnen, welches Segment als
; nächstest ausgegeben werden muss
ldi ZL, LOW( Segment0 )
ldi ZH, HIGH( Segment0 )
lds temp, NextSegment
add ZL, temp
adc ZH, temp1

ld temp, Z ; das entsprechende Muster holen und ausgeben
out PORTD, temp

lds temp1, NextDigit ; Und die betreffende Stelle einschalten
out PORTC, temp1

lds temp, NextSegment
inc temp
sec
rol temp1 ; beim nächsten Interrupt kommt reihum die
cpi temp1, 0b11101111 ; nächste Stelle dran.
brne multi1
ldi temp, 0
ldi temp1, 0b11111110

multi1:
sts NextSegment, temp
sts NextDigit, temp1

pop ZH ; die gesicherten Register wiederherstellen
pop ZL
pop temp
out SREG, temp
pop temp1
pop temp
reti
;
;************************************************************************
; 16 Bit-Zahl aus dem Registerpaar temp (=low), temp1 (=high) ausgeben
; die Zahl muss kleiner als 10000 sein, da die Zehntausenderstelle
; nicht berücksichtigt wird.
; Werden mehr als 4 7-Segmentanzeigen eingesetzt, dann muss dies
; natürlich auch hier berücksichtigt werden
;
out_number:
push temp
push temp1

ldi temp2, -1 ; Die Tausenderstelle bestimmen
_out_tausend:
inc temp2
subi temp, low(1000) ; -1000
sbci temp1, high(1000)
brcc _out_tausend

ldi ZL, low(2*Codes) ; fuer diese Ziffer das Codemuster fuer
ldi ZH, high(2*Codes) ; die Anzeige in der Codetabelle nachschlagen
add ZL, temp2

lpm
sts Segment3, r0 ; und dieses Muster im SRAM ablegen
; die OvI Routine sorgt dann duer die Anzeige
ldi temp2, 10

_out_hundert: ; die Hunderterstelle bestimmen
dec temp2
subi temp, low(-100) ; +100
sbci temp1, high(-100)
brcs _out_hundert

ldi ZL, low(2*Codes) ; wieder in der Codetabelle das entsprechende
ldi ZH, high(2*Codes) ; Muster nachschlagen
add ZL, temp2

lpm
sts Segment2, r0 ; und im SRAM hinterlassen

ldi temp2, -1
_out_zehn: ; die Zehnerstelle bestimmen
inc temp2
subi temp, low(10) ; -10
sbci temp1, high(10)
brcc _out_zehn

ldi ZL, low(2*Codes) ; wie gehabt: Die Ziffer in der Codetabelle
ldi ZH, high(2*Codes) ; aufsuchen
add ZL, temp2

lpm
sts Segment1, r0 ; und entsprechend im SRAM ablegen

_out_einer: ; bleiben noch die Einer
subi temp, low(-10) ; +10
sbci temp1, high(-10)

ldi ZL, low(2*Codes) ; ... Codetabelle
ldi ZH, high(2*Codes)
add ZL, temp

lpm
sts Segment0, r0 ; und ans SRAm ausgeben

pop temp1
pop temp

ret
;
;**************************************************************************
;
main:
ldi temp, HIGH(RAMEND)
out SPH, temp
ldi temp, LOW(RAMEND) ; Stackpointer initialisieren
out SPL, temp
; die Segmenttreiber initialisieren
ldi temp, $FF
out DDRD, temp
; die Treiber für die einzelnen Stellen
ldi temp, $0F
out DDRC, temp
; initialisieren der Steuerung für die
; Interrupt Routine
ldi temp, 0b11111110
sts NextDigit, temp

ldi temp, 0
sts NextSegment, temp

ldi temp, ( 1 << CS01 ) | ( 1 << CS00 )
out TCCR0, temp

ldi temp, 1 << TOIE0
out TIMSK, temp

sei

ldi temp, 0
ldi temp1, 0

loop:
inc temp
brne _loop
inc temp1
_loop:
rcall out_number

cpi temp, low( 4000 )
brne wait
cpi temp1, high( 4000 )
brne wait

ldi temp, 0
ldi temp1, 0

wait: ldi r21, 1
wait0: ldi r22, 0
wait1: ldi r23, 0
wait2: dec r23
brne wait2
dec r22
brne wait1
dec r21
brne wait0

rjmp loop

Codes:
.db 0b11000000, 0b11111001 ; 0: a, b, c, d, e, f
; 1: b, c
.db 0b10100100, 0b10110000 ; 2: a, b, d, e, g
; 3: a, b, c, d, g
.db 0b10011001, 0b10010010 ; 4: b, c, f, g
; 5: a, c, d, f, g
.db 0b10000010, 0b11111000 ; 6: a, c, d, e, f, g
; 7: a, b, c
.db 0b10000000, 0b10010000 ; 8: a, b, c, d, e, f, g
; 9: a, b, c, d, f, g

.DSEG
NextDigit: .byte 1 ; Bitmuster für die Aktivierung des nächsten Segments
NextSegment: .byte 1 ; Nummer des nächsten aktiven Segments
Segment0: .byte 1 ; Ausgabemuster für Segment 0
Segment1: .byte 1 ; Ausgabemuster für Segment 1
Segment2: .byte 1 ; Ausgabemuster für Segment 2
Segment3: .byte 1 ; Ausgabemuster für Segment 3
</syntaxhighlight>

== Forenbeiträge ==
*[http://www.mikrocontroller.net/topic/154257 Geisterleuchten bei 7-Segment Anzeige]

*[http://www.mikrocontroller.net/topic/262337#2736074 Re: Zehn 7Segmente im Multiplexbetrieb : Hilfe !] - Ausführliche Erklärung wie und warum man entweder die '''Stellen''' oder die '''Segmente''' multiplext.

----

{{Navigation_zurückhochvor|
zurücktext=SRAM|
zurücklink=AVR-Tutorial: SRAM|
hochtext=Inhaltsverzeichnis|
hochlink=AVR-Tutorial|
vortext=Servos|
vorlink=AVR-Tutorial: Servo}}

[[Category:AVR-Tutorial|7-Segment-Anzeige]]
[[Category:Displays und Anzeigen]]