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

Inline-Assembler in avr-gcc

2006-12-29T10:49:56Z

Heigro: Typo

In C versteht man unter '''Inline Assembler''' die Möglichkeit, direkt Assembler-Befehle in den Code einzufügen bzw. die eingefügten Assembler-Befehle selbst.

Neben den einzufügenden Befehlen muss beschrieben werden, welche Nebeneffekte die Befehle auf die Maschine haben und wo/wie Parameter übergeben werden, bzw. wie die Zuordnung von Variablen zu den Registern ist. Diese Beschreibung ist notwendig weil der [[Compiler]] keine Vorstellung davon hat, welche Effekte und Nebenwirkungen die Assembler-Kommandos auf Register, Variablen und Speicher haben, denn der Assembler-Schnippsel ist für den Compiler lediglich eine "Black Box".

Obgleich das dazu verwendete Schlüsselwort <tt>__asm</tt> zum ANSI-C-Standard gehört, ist dies in jedem C-Compiler anders implementiert. Das gilt insbesondere für die Schnittstellenbeschreibung Variablen/Register. Dieser Artikel bezieht sich auf den Inline Assembler von [[avr-gcc]].
Viele Erklärungen aus diesem Artikel sind auch gültig für Inline-Assembler anderer C-Compiler der [[gcc]]-Familie. Instruktionen und Registerklassen werden sich aber unterscheiden, weil diese natürlich abhängig sind vom verwendeten Controller bzw. der Controller-Familie.

=Assembler oder Inline-Assembler?=
;Assembler: Längere und komplexere Code-Stücke sind komfortabler direkt in Assembler auszudrücken. Dazu schreibt man Assembler-Funktionen und ruft diese von C aus auf. Natürlich können auch C-Funktionen von Assembler aus aufgerufen werden. Zudem kann man im Assembler den C-Präprozessor nutzen, was bei Inline-Assembler nur auf C-Ebene geht. Der Build-Prozess wird allerdings komplizierter, da extra asm-Dateien übersetzt werden müssen.
;Inline-Assembler: Mit Inline-Assembler kann man kleine Assembler-Stückchen direkt in den C-Code einbetten. Es muss dann keine Assembler-Funktion aufgerufen werden. Dies kann von der Registerverwendung her deutlich günstiger sein, da [[avr-gcc]] genau weiß, welche Register gebraucht werden und welche nicht. Eine Funktion hingegen ist eine Black Box, bei der von der Standard-[[avr-gcc/Interna#Registerverwendung|Registerverwendung]] ausgegangen werden muss, auch wenn weniger Register in einer Funktion verwendet werden. Ein Funktionsaufruf bedeutet also meistens einen Laufzeit-Overhead im Vergleich zu einem Inline-Code. Bei mehrfacher Verwendung einer längeren Codesequenz ist eine Funktion jedoch sparsamer im Flash-Verbrauch. Legt man eine Funktion als C-Funktion an und ihren Body als Inline-Assembler (eine s.g. Stub-Funktion, von engl. ''Stub'' = Stumpf), dann übernimmt gcc das Verwalten von Funktions-Argumenten, return-Wert, etc. und man brauch sich nicht selber um die Aufruf-Konvention zu kümmern. Auch innerhalb einer Funktion kann C mit Assembler gemischt werden.

=Begriffe=
;Assembler-Template: Das Template (''Schablone'') ist ein statischer, konstanter String im Sinne von C. Es enthält die Assembler-Befehle sowie Platzhalter, in deren Stelle später die Operanden treten
;Constraint: Die Constraints (''Nebenbedingungen'') beschreiben Einschränkungen an die zu verwendeten Register. Dies ist notwendig, da nicht alle Maschinenbefehle auf alle Register anwendbar sind
;Clobber-List: Das ist eine Liste von Registern, deren Inhalt durch den Inline-Assembler zerstört wird

=Syntax und Semantik=
Das Schlüsselwort, um eine Inline-Assembler Sequenz einzuleiten, ist <tt>__asm</tt> (ANSI). Oft ist auch <tt>asm</tt> oder <tt>__asm__</tt> verwendbar. Um zu kennzeichnen, daß die Sequenz keinesfalls wegoptimiert werden darf – etwa dann, wenn der Assembler keine Wirkung auf C-Variablen hat – wird dem <tt>asm</tt> ein <tt>volatile</tt> bzw. <tt>__volatile</tt> nachgestellt. Danach folgen in runden Klammern die durch <tt>''':'''</tt> getrennten Abschnitte des Inline-Assemblers:
asm volatile ([[#Assembler-Template|asm-template]] : [[#Operanden und Constraints|output-operand-list]] : [[#Operanden und Constraints|input-operand-list]] : [[#Clobbers|clobber-list]]);

Abschnitte, die leer sind, können auch weggelassen werden, wenn dahinter kein weiterer Abschnitt folgt:
asm volatile (asm-template);

Oder, wenn weder Input- noch Output-Operanden gebraucht werden, aber Register oder Speicher verändert werden:
asm volatile (asm-template ::: clobber-list);

{{FarbigerRahmen |
Aus Compiler-Sicht werden die Assembler-Befehle im Template parallel, also ''gleichzeitig'' ausgeführt! Dies ist zu bedenken, wenn Register sowohl als Input als auch als Output verwendet werden.
}}

==Assembler-Template==

Im Template stehen die durch Zeilenumbrüche getrennten Assembler-Befehle. Das Template kann zudem <tt>%</tt>-Ausdrücke als Platzhalter enthalten, welche durch die Operanden ersetzt werden. Dabei bezieht sich <tt>%0</tt> auf den ersten Operanden, <tt>%1</tt> auf den zweiten Operanden, etc. Die Operanden selbst werden im zweiten und dritten Abschnitt des Templates als Komma-getrennte Liste angegeben.

Ein Platzhalter kann zusätzlich einen einbuchstabigen Modifier enthalten, um ein Register in einem speziellen Format darzustellen. Wird z.B. ein Wert ab Register <tt>r28</tt> (dem Y-Register) gehalten, dann wären folgende Ersetzungen denkbar (als erstes Argument):

<center>
<tt>%0     →  r28</tt>

<tt>%A0    →  r28</tt>

<tt>%B0    →  r29</tt>

<tt>%C0    →  r30</tt>

<tt>%D0    →  r31</tt>

<tt>%a0    →  y  </tt>
</center>

Im einfachsten Falle enthält das Templater nur einen Befehl:
"nop"
oder sogar garkeinen Befehl und lediglich einen Kommentar:
"; ein Kommentar"

<center>
{| {{Blauetabelle}}
|+ '''Tabelle: asm-Platzhalter und ihre Modifier, Sonderzeichen'''
|- {{Hintergrund1}}
! Platzhalter || wird ersetzt durch
|-
|<tt>%''n''</tt> || Wird ersezt durch Argument <tt>''n''</tt> mit <tt>''n''</tt> = 0...9
|-
|<tt>%A''n''</tt> || das erste (untere) Register des Arguments <tt>''n''</tt> (Bits 0...7)
|-
|<tt>%B''n''</tt> || das zweite Register des Arguments <tt>''n''</tt> (Bits 8...15)
|-
|<tt>%C''n''</tt> || das dritte Register des Arguments <tt>''n''</tt> (Bits 16...23)
|-
|<tt>%D''n''</tt> || das vierte Register des Arguments <tt>''n''</tt> (Bits 24...31)
|-
|<tt>%a''n''</tt> || Ausgabe des Arguments als Adress-Register, also als <tt>x</tt>, <tt>y</tt> bzw. <tt>z</tt>. Erlaubt zusammen mit Constraint <tt>b</tt>, <tt>e</tt>, <tt>x</tt>, <tt>y</tt>, <tt>z</tt>
|-
|<tt>%~</tt> || wird auf AVR mit Flash bis max. 8kByte durch ein <tt>r</tt> ersetzt, ansonsten bleibt es leer. Zum Aufbau von Sprungbefehlen, etwa "<tt>%~call foo</tt>"
|-
|<tt>%=</tt> || eine für dieses asm-Template und die Übersetzungseinheit eindeutige Zahl. Zum Aufbau lokaler Sprungmarken.
|- {{Hintergrund1}}
! Sequenz || wird ersetzt durch Sonderzeichen
|-
|<tt>%%</tt> || das <tt>%</tt>-Zeichen selbst
|-
|<tt>\n</tt> || ein Zeilenumbruch zum Trennen mehrerer asm-Befehle/Zeilen
|-
|<tt>\t</tt> || ein TAB, zur Übersichtlichkeit im erzeugten asm
|-
|<tt>\"</tt> || ein <tt>"</tt> wird eingefügt
|-
|<tt>\\</tt> || das <tt>\</tt>-Zeichen selbst
|- {{Hintergrund1}}
! Kommentar || Beschreibung
|-
|<tt>; ''Text''</tt> || einzeiliger Kommentar bis zum Ende des Templates bzw. nächsten Zeilenumbruch
|-
|<tt>/* ''Text'' */</tt> || mehrzeiliger Kommentar wie in C
|}
</center>

==Operanden und Constraints==

Ein Operand besteht aus der Angabe des Constraint-Strings (also der Registerklasse und Kennzeichnung, ob es sich um einen Output-Operanden handelt) und dahinter in runden Klammern der C-Ausdruck, der in Register der angegebenen Klasse geladen werden soll. Die Operanden werden mit 0 beginnend von links nach rechts durchnumeriert und über diese Nummer angesprochen, um sie ins Assembler-Schnippsel einzufügen.

Mehrere Input- bzw. Output-Operanden werden durch Komma getrennt.

<center>
{| {{Blauetabelle}}
|+ '''Tabelle: Constraints und ihre Bedeutung'''
|- {{Hintergrund1}}
! Constraint || Register || Wertebereich
|rowspan="14"| 
! Constraint || Konstante || Wertebereich
|-
|<tt>a</tt>||einfache obere Register||<tt>r16</tt>...<tt>r23</tt>
|<tt>G</tt>||Floatingpoint-Konstante ||<tt>0.0</tt>
|-
|<tt>b</tt>||Pointer-Register ||<tt>y</tt>, <tt>z</tt>
|<tt>i</tt>||Konstante || 
|-
|<tt>d</tt>||obere Register ||<tt>r16</tt>...<tt>r31</tt>
|<tt>I</tt>||positive 6-Bit-Konstante ||0...63
|-
|<tt>e</tt>||Pointer-Register ||<tt>x</tt>, <tt>y</tt>, <tt>z</tt>
|<tt>J</tt>||negative 6-Bit Konstante ||<tt>-</tt>63...0
|-
|<tt>l</tt>||untere Register ||<tt>r0</tt>...<tt>r15</tt>
|<tt>M</tt>||8-Bit Konstante ||0...255
|-
|<tt>q</tt>||Stack-Pointer ||<tt>SPH:SPL</tt>
|colspan="3" | 
|-
|<tt>r</tt>||ein Register ||<tt>r0</tt>...<tt>r31</tt>
!{{Hintergrund1}}| Constraint ||{{Hintergrund1}}| Memory ||{{Hintergrund1}}| Wertebereich
|-
|<tt>t</tt>||Scratch-Register ||<tt>r0</tt>
|<tt>m</tt>|| Memory ||  
|-
|<tt>w</tt>||obere Register-Paare ||<tt>r24</tt>, <tt>r26</tt>, <tt>r28</tt>, <tt>r30</tt>
|colspan="3" rowspan="5"| 
|-
|<tt>x</tt>||Pointer-Register X ||<tt>x</tt> (<tt>r27:r26</tt>)
|-
|<tt>y</tt>||Pointer-Register Y ||<tt>y</tt> (<tt>r29:r28</tt>)
|-
|<tt>z</tt>||Pointer-Register Z ||<tt>z</tt> (<tt>r31:r30</tt>)
|-
|<tt>0</tt>...<tt>9</tt>||colspan="2"|Identisch mit dem angegebenen Operanden Wird verwendet, wenn ein Operand sowohl als Input als auch als Output dient, um sich auf diesen Operanden zu beziehen
|}
</center>

<center>
{| {{Blauetabelle}}
|+ '''Tabelle: Constraint Modifier'''
|- {{Hintergrund1}}
!Modifier || Bedeutung
|-
|<tt>=</tt> || der Operand ist Output-Operand
|-
|<tt>&</tt> || diesen Operanden ''nicht'' als Input-Operanden verwenden, sondern nur als Output-Operand
|}
</center>

Ein Input-Operand könnte also so aussehen, wobei <tt>foo</tt> eine C-Variable ist. Als Register dient ein (je nach Typ von <tt>foo</tt> auch mehrere) obere Register, irgendwo von <tt>r16</tt> bis <tt>r31</tt> (Constraint <tt>"d"</tt>):
"d" (foo)

In den Klammern kann ein beliebiger, gültiger C-Ausdruck stehen, der beim folgenden Beispiel in irgendeinem Register landet (Constraint <tt>"r"</tt>), ohne weitere Einschränkung an das Register:
"r" ((foo >= 0) ? foo : -foo)

Um einen Operanden als Output-Operanden zu kennzeichnen, wird dem Constraint ein <tt>"="</tt> vorangestellt.
Soll <tt>foo</tt> ein Output-Operand sein, der in den Registern <tt>r0</tt>...<tt>r15</tt> landen soll (Constraint <tt>"l"</tt>, sieht es so aus. Dabei muss <tt>foo</tt> ein sogenannter Lvalue sein, also ein Wert, dem etwas zugewiesen werden kann:
"=l" (foo)

Ist <tt>foo</tt> sowohl Input als auch Output, schreibt man <tt>foo</tt> als Output- und als Input-Operand hin. In der Input-Constraint bezieht man sich dann auf die Operanden-Nummer von <tt>foo</tt>. Hier ein komplettes Beispiel, das die Nibbles von <tt>foo</tt> tauscht. Weil <tt>swap</tt> auf alle Register anwendbar ist, kann als Registerklasse <tt>"r"</tt> genommen werden:
<pre>
unsigned char foo;
...
asm volatile ("swap %0" : "=r" (foo) : "0" (foo));
</pre>
<tt>foo</tt> als Input-Operand soll im gleichen Register liegen wie <tt>foo</tt> als Output-Operand. Daher wird als Constraint <tt>"0"</tt> angegeben, d.h. es wird ins gleiche Register geladen wie der Operand Numero 0 <tt>"r" (foo)</tt>.

===Instruktionen und Constraints===
Die folgende Tabelle enhält eine Auflistung von AVR-Instruktionen und dazu passende Argumente bzw. Constraints. Nicht alle Shorthands sind in der Tabelle enthalten, so ist "<tt>clr Rn</tt>" nur eine Abkürzung für "<tt>eor Rn, Rn</tt>", ähnliches gilt für den Zoo von Instruktionen rund um das SREG wie branch, bit set, bit clear, etc., die im Endeffekt auf nur vier Instruktionen abbilden. Instruktionen wie <tt>nop</tt>, die keine Argumente brauchen, sind ebenfalls nicht in der Tabelle enthalten.

<tt>"load"</tt> ist ein <tt>"load from SRAM"</tt> 
<tt>"store"</tt> ist <tt>"store to SRAM"</tt> 

<center>
{| {{Blauetabelle}}
|+'''Tabelle: Übersicht AVR-Instruktionen und passende Constraints'''
|- {{Hintergrund1}}
!Mnemonic || Constraint ||Bedeutung ||rowspan="30"| 
!Mnemonic || Constraint ||Bedeutung
|-
| <tt>adc</tt>||<tt>r,r</tt> || add with carry
| <tt>add</tt>||<tt>r,r</tt> || add
|-
| <tt>adiw</tt>||<tt>w,I</tt> || add immediate to word
| <tt>and</tt>||<tt>r,r</tt> || and
|-
| <tt>andi</tt>||<tt>d,M</tt> || and with immediate
| <tt>asr</tt>||<tt>r</tt> || arithmetic shift right
|-
| <tt>bclr</tt>||<tt>I</tt> || bit clear in SREG
| <tt>bld</tt>||<tt>r,I</tt> || bit load from T
|-
| <tt>brbc</tt>||<tt>I,label</tt> || branch if bit in SREG clear
| <tt>brbs</tt>||<tt>I,label</tt> || branch if bit in SREG set
|-
| <tt>bset</tt>||<tt>I</tt> || bit set in SREG
| <tt>bst</tt>||<tt>r,I</tt> || bit store from T
|-
| <tt>cbi</tt>||<tt>I,I</tt> || clear bit in I/O
| <tt>com</tt>||<tt>r</tt> || complement
|-
| <tt>cp</tt>||<tt>r,r</tt> || compare
| <tt>cpc</tt>||<tt>r,r</tt> || compare with carry
|-
| <tt>cpi</tt>||<tt>d,M</tt> || compare against immediate
| <tt>cpse</tt>||<tt>r,r</tt>|| compare, skip if equal
|-
| <tt>dec</tt>||<tt>r</tt> || decrement
| <tt>elpm</tt>||<tt>t,z</tt>|| extern: load from prog mem
|-
| <tt>eor</tt>||<tt>r,r</tt> || exclusive-or
| <tt>in</tt>||<tt>r,I</tt> || input from I/O
|-
| <tt>inc</tt>||<tt>r</tt> || increment
| <tt>ld</tt>||<tt>r,e</tt> || load indirect
|-
| <tt>ld</tt>||<tt>r,e+</tt> || load indirect, post-increment
| <tt>ld</tt>||<tt>r,-e</tt> || load indirect, pre-decrement
|-
| <tt>ldd</tt>||<tt>r,b+I</tt> || load indirect with displacement
| <tt>ldi</tt>||<tt>d,M</tt> || load immediate
|-
| <tt>lds</tt>||<tt>r,label</tt> || load direct from SRAM
| <tt>lpm</tt>||<tt>t,z</tt> || load from prog mem
|-
| <tt>lsr</tt>||<tt>r</tt> || logical shift right
| <tt>mov</tt>||<tt>r,r</tt> || move
|-
| <tt>movw</tt>||<tt>r,r</tt> || move word
| <tt>mul</tt>||<tt>r,r</tt> || mul
|-
| <tt>neg</tt>||<tt>r</tt> || negate
| <tt>or</tt>||<tt>r,r</tt> || or
|-
| <tt>ori</tt>||<tt>d,M</tt> || or with immediate
| <tt>out</tt>||<tt>I,r</tt> || output to I/O
|-
| <tt>pop</tt>||<tt>r</tt> || pop from Stack
| <tt>push</tt>||<tt>r</tt> || push to Stack
|-
| <tt>ror</tt>||<tt>r</tt> || rotate right
|colspan="3"|  
|-
| <tt>sbc</tt>||<tt>r,r</tt> || subtract with carry
| <tt>sbci</tt>||<tt>d,M</tt> || subtract with carry immediate
|-
| <tt>sbic</tt>||<tt>I,I</tt> || skip if bit in I/O clear
| <tt>sbis</tt>||<tt>I,I</tt> || skip if bit in I/O set
|-
| <tt>sbi</tt>||<tt>I,I</tt> || set Bit in I/O
| <tt>sbiw</tt>||<tt>w,I</tt> || subtract immediate from word
|-
| <tt>sbrc</tt>||<tt>r,I</tt> || skip if bit in register clear
| <tt>sbrs</tt>||<tt>r,I</tt> || skip if bit in register set
|-
| <tt>st</tt>||<tt>e,r</tt> || store indirect
| <tt>st</tt>||<tt>e+,r</tt> || store indirect, post-increment
|-
| <tt>st</tt>||<tt>-e,r</tt> || store indirect, pre-decrement
| <tt>std</tt>||<tt>b,r</tt> || store indirect with displacement
|-
| <tt>sts</tt>||<tt>label,r</tt> || store direct
| <tt>sub</tt>||<tt>r,r</tt> || subtract
|-
| <tt>subi</tt>||<tt>d,M</tt> || subtract immediate
| <tt>swap</tt>||<tt>r</tt> || swap nibbles

|}
</center>

Hier noch ein paar der gebräuchlichsten Shorthands und deren Abbildung auf "Basis"-Instruktionen:
<center>
{| {{Blauetabelle}}
|+'''Tabelle: Shorthands'''
|- {{Hintergrund1}}
!Shorthand || gleichbedeutend mit || Bedeutung ||rowspan="5"| 
!Shorthand || gleichbedeutend mit || Bedeutung
|-
| <tt>asl r</tt> || <tt>addc r,r</tt> || arithmetic shift left
| <tt>cbr r,M</tt> || <tt>andi r, ~M</tt> || clear bits in reg
|-
| <tt>clr r</tt> || <tt>eor r,r</tt> || clear reg to zero
| <tt>lsl r</tt> || <tt>add r,r</tt> || logical shift left
|-
| <tt>sbr d,M</tt> || <tt>ori d, M</tt> || set bits in reg
| <tt>ser d</tt> || <tt>ldi d, 0xff</tt> || set all bits in reg
|-
| <tt>tst r</tt> || <tt>and r,r</tt> || test against zero
|colspan="3"| 
|}
</center>

==Clobbers==

In der Komma-getrennten Clobber-Liste kann man angeben, welche Register durch den Inline-Assembler ihren Wert ändern. Ändern z.B. <tt>r2</tt> und <tt>r3</tt> ihre Werte, dann ist die Clobber-Liste
"r2", "r3"

Wird schreibend auf das RAM zugegriffen, dann muss man das auch mitteilen, damit RAM-Inhalte, die sich evtl. in Registern befinden, nach dem Inline-Assembler neu gelesen werden. Der Clobber dafür ist:
"memory"

'''Beispiel:'''

Es soll ein Inline-Assembler geschrieben werden, das den Inhalt zweier aufeinanderfolgender Speicherstellen austauscht. Die Adresse soll in <tt>addr</tt> stehen. Sie ist Input-Operand und muss in Register X, Y oder Z stehen, um den <tt>ld</tt> bzw. <tt>st</tt>-Befehl anwenden zu können. Die passende Constraint ist also <tt>"e"</tt>. Nach der Sequenz liegt <tt>addr</tt> unverändert vor.
<pre>
asm volatile (
"ld r2, %a0+" "\n\t"
"ld r3, %a0" "\n\t"
"st %a0, r2" "\n\t"
"st -%a0, r3"
: /* keine Output-Operanden */
: "e" (addr)
: "r2", "r3", "memory"
);
</pre>
avr-gcc entscheidet sich dazu, das Z-Register für <tt>addr</tt> zu verwenden:
<pre>
ld r2, Z+
ld r3, Z
st Z, r2
st -Z, r3
</pre>

Günstiger ist es jedoch, dem Compiler auch die Entscheidung zu überlassen, welche(s) Register als Hilfsregister verwendet werden sollen. Ein Register kann <tt>__tmp_reg__</tt> sein, für das zweite legen wir eine lokale 8-Bit-Variable <tt>hilf</tt> an:
<pre>
{
char hilf;

asm volatile (
"ld __tmp_reg__, %a1+" "\n\t"
"ld %0, %a1" "\n\t"
"st %a1, __tmp_reg__" "\n\t"
"st -%a1, %0"
: "=&r" (hilf)
: "e" (addr)
: "memory"
);
}
</pre>
<tt>__tmp_reg__</tt> (also <tt>r0</tt>) brauch nicht in die Clobber-Liste aufgenommen zu werden. Um das zweite benötigte Register (hier <tt>r24</tt>, in dem <tt>hilf</tt> lebt) kümmert sich avr-gcc und sichert es, falls nötig
<pre>
ld r0, Z+
ld r24, Z
st Z, r0
st -Z, r24
</pre>

{{FarbigerRahmen |
Falls das Register <tt>r1</tt> verändert wird – was z.B. geschieht, wenn man Multiplikationsbefehle verwendet – dann muss am Ende des Templates das Register wieder auf 0 gesetzt werden, denn bei avr-gcc enthält dieses Register immer den Wert 0.
Das Register in die Clobber-Liste aufzunehen bleibt wirkungslos. Hat man es zerstört,
dann schreibt man ans Ende des Templates ein
clr __zero_reg__
und stellt es dadurch wieder her.
}}

=Vordefinierte Bezeichner und Makros=
Je nach Assembler, für den avr-gcc Code erzeugt, gibt es unterschiedliche vordefinierte Funktionen/Makros, die von Inline-Assembler aus verwendbar sind.
== GNU-Assembler ==
<center>
{| {{Blauetabelle}}
|+ '''Tabelle: vordefinierte Bezeichner/Makros
|- {{Hintergrund1}}
! Bezeichner || Bedeutung
|-
|<tt>__SP_L__</tt> || unteres Byte des Stack-Pointers, für <tt>in</tt> bzw. <tt>out</tt>
|-
|<tt>__SP_H__</tt> || oberes Byte des Stack-Pointers, für <tt>in</tt> bzw. <tt>out</tt>
|-
|<tt>__SREG__</tt> || Status-Register, für <tt>in</tt> bzw. <tt>out</tt>
|-
|<tt>__tmp_reg__</tt> || ein Register zur temporären Verwendung (<tt>r0</tt>)
|-
|<tt>__zero_reg__</tt> || ein Register, das 0 enthält (<tt>r1</tt>)
|-
|<tt>lo8(''const'')</tt> || die unteren 8 Bit der Konstanten <tt>''const''</tt>
|-
|<tt>hi8(''const'')</tt> || Bits 8...15 der Konstanten <tt>''const''</tt>
|-
|<tt>hlo8(''const'')</tt> || Bits 16...23 der Konstanten <tt>''const''</tt>
|-
|<tt>hhi8(''const'')</tt> || Bits 24...31 der Konstanten <tt>''const''</tt>
|}
</center>

=Beispiele=

==nop==
Mit den bisherigen Vorkenntnissen ist zu <tt>nop</tt> nicht viel zu sagen:
asm volatile ("nop");
Oder als C-Makro:
#define nop() \
asm volatile ("nop")

<tt>nop</tt> hat weder Input- noch Output-Operanden, und Register/RAM ändern sich natürlich nicht. Bei der Makro-Definition ist lediglich darauf zu achten, daß das Makro nicht mit einem <tt>;</tt> endet, damit man den C-Code wie gewohnt mit <tt>;</tt> schreiben kann:
<pre>
if (x)
nop();
else
...
</pre>

==swap Nibbles==
Ein einfaches Beispiel für <tt>swap</tt> haben wir bereits oben kennen gelernt. Der Inline-Assembler dreht die Nibbles von <tt>foo</tt> um:
<pre>
unsigned char foo;
...
asm volatile ("swap %0" : "=r" (foo) : "0" (foo));
</pre>

Wünschenswert wäre eher, <tt>swap</tt> wie eine normale C-Funktion verwenden zu können und hinzuschreiben:
a = swap(b);
ohne daß <tt>b</tt> seinen Wert ändert. Soll <tt>b</tt> geswappt werden, dann via
b = swap(b);
zudem soll das Argument ein Ausdruck sein können:
if (b == swap (b+1))
...

Dazu verwenden wir eine lokale Variable <tt>__x__</tt>, in die der ursprüngliche Wert <tt>x</tt> gesichert wird:
<pre>
#define swap(x) \
({ \
unsigned char __x__ = (unsigned char) x; \
asm volatile ("swap %0" : "=r" (__x__) : "0" (__x__)); \
__x__; \
})
</pre>
alternativ könnten wie eine inline-Funktion definieren:
<pre>
static inline unsigned char swap (unsigned char x)
{
asm volatile ("swap %0" : "=r" (x) : "0" (x));
return x;
}
</pre>

==swap Bytes==
Werden Zahlen zwischen verschiedenen Plattformen übertragen, kann es sein, daß diese unterschiedlich dargestellt werden: Das low-Byte kann in sich im unteren Byte befinden (AVR), es kann aber auch im oberen Byte sein. Ist das so, dann müssen die Werte beim Senden/Empfang umgewandelt werden, indem die Bytes getauscht werden. Liegt der 16-Bit-Wert in <tt>x_in</tt> und soll der konvertierte Wert nach <tt>x_out</tt>gespeichert werden, dann könnte man auf die Idee kommen, so etwas zu schreiben:
<pre>
asm volatile (
"mov %A0, %B1" "\n\t"
"mov %B0, %A1"
: "=r" (x_out)
: "r" (x_in)
);
</pre>
Daraus könnte folgender Code entstehen:
<pre>
mov r24, r25
mov r25, r24
</pre>
Das ist offenbar Käse! Was ist passiert?

avr-gcc hat sich dazu entschieden, <tt>x_in</tt> in <tt>r25:r24</tt> anzulegen. Auch <tt>x_out</tt> wird in diesen Registern angelegt. Das ist erst mal in Ordnung, wenn <tt>x_in</tt> nach dem Inline nicht mehr gebraucht wird. Allerdings wird das Inline nicht en bloc – also nicht zeitparallel – ausgeführt, sondern sequenziell. Bei ''gleichzeitiger'' Ausführung der beiden <tt>mov</tt>-Instruktionen wäre auch nichts dagegen zu sagen. Ein <tt>swap</tt>-Kommando z.B. tauscht die Nibbles gleichzeitig, und der Input-Operand kann im gleichen Register leben wie der Output-Operand, wenn der Input nicht weiter verwendet wird. Mit den beiden Bytes geht es aber nicht. Wir müssen kennzeichnen, daß sich <tt>x_out</tt> in einem Register befindet, das ''nur'' als Output dient, was durch das <tt>&</tt> in der Output-Constraint erreicht wird:
<pre>
asm volatile (
"mov %A0, %B1" "\n\t"
"mov %B0, %A1"
: "=&r" (x_out)
: "r" (x_in)
);
</pre>
Damit erfolgt eine korrekte Registerzuordnung. <tt>x_out</tt> steht jetzt in <tt>r19:r18</tt> und überschneidet nich nicht mehr mit <tt>x_in</tt>:
<pre>
mov r18, r25
mov r19, r24
</pre>

Alternativ können wir wie bei [[#swap Nibbles|swap Nibbles]] eine lokale Variable verwenden, und alles als (inline-)Funktion machen. In dem folgenden Beispiel wird ein etwas anderer Code zum Tauschen verwendet:
<pre>
static inline unsigned short swap_16 (unsigned short x_in)
{
asm volatile (
"eor %A0, %B0" "\n\t"
"eor %B0, %A0" "\n\t"
"eor %A0, %B0"
: "=r" (x_in)
: "0" (x_in)
);

return x_in;
}
</pre>
Die <tt>eor</tt>-Sequenz tauscht die Inhalte von <tt>r24</tt> und <tt>r25</tt>. Sie ist genauso schnell und knapp wie ein "Dreiecks-Tausch", kommt aber ohne Hilfsregister aus. Nachrechnen, es stimmt!
<pre>
eor r24, r25
eor r25, r24
eor r24, r25
</pre>

== Zugriff auf SFRs ==
Um auf SFRs zuzugreifen, können im asm-Template keine Defines aus <tt>avr/io.h</tt> verwendet werden, weil der Präprozessor nicht mehr über den erzeugten Assembler-Code läuft (er läuft vor dem Compilieren). Um nicht die hex-Codes des SFRs angeben zu müssen, kann man dem Inline die Adressen als Konstanten übergeben. Weil die Adressen RAM-Adressen sind, müssen sie in das <tt>_SFR_IO_ADDR</tt> Makro verpackt werden, um den Offset für den I/O-Bereich abzuziehen. <tt>tcnt1</tt> wird auf den Inhalt von <tt>TCNT1</tt> gesetzt:
<pre>
#include <avr/io.h>
...
uint16_t tcnt1;

asm volatile (
"in %A0, %1" "\n\t"
"in %B0, %1+1"
: "=r" (tcnt1)
: "M" (_SFR_IO_ADDR (TCNT1))
);
</pre>
wird umgesetzt zu
<pre>
in r24, 44
in r25, 44+1
</pre>
Das nur als Beispiel. Von C aus geht das natürlich auch mit
uint16_t tcnt1 = TCNT1;

== Zugriff aufs SRAM ==
Auf bekannte globale Symbole kann man direkt von Assembler aus zugreifen:
<pre>
extern int einInt;

asm volatile (
"lds %A0, einInt" "\n\t"
"lds %B0, einInt+1"
: "=r" (...)
);
</pre>
ergibt
<pre>
lds r24, einInt
lds r25, einInt+1
</pre>
alternativ ginge
<pre>
asm volatile (
"lds %A0, %A1" "\n\t"
"lds %B0, %B1"
: "=r" (...)
: "m" (einInt)
);
</pre>

Falls die Adresse eines Objekts zur Compilezeit bekannt ist, kann man auch die Adresse von C aus übergeben:
<pre>
struct foo_t {
int a[2], b[2];
} foo;

...
{
asm volatile (
"lds %A0, %1" "\n\t"
"lds %B0, %1+1"
: "=r" (...)
: "i" (& foo.b[1])
);
}
</pre>
ergibt
<pre>
lds r24, einStruct+6
lds r25, einStruct+6+1
</pre>

Falls die Adresse zur Compilezeit nicht bekannt ist, muss sie natürlich in einem Adress- oder Basisregister übergeben werden:
<pre>
void blah (struct foo_t * pfoo)
{
asm volatile (
"ld %A0, %a1" "\n\t"
"ldd %B0, %a1+1"
: "=&r" (...)
: "b" (& pfoo->b[1])
);
}
</pre>
ergibt
<pre>
ld r24, Z
ldd r25, Z+1
</pre>
Auch hier muss der Output-Operand mit einem <tt>&</tt> gekennzeichnet werden, damit er nicht ins gleiche Register geladen wird wie die Adresse.

== Labels und Schleifen ==
Für Labels in Sprüngen und Schleifen können keine festen Bezeichner verwendet werden, weil ein Label, der via Makro oder inline-Funktion in den Code eingefügt wird, nicht mehrfach vorkommen darf. Dazu kann man sich durch Einfügen von <tt>"%="</tt> Labels zusammenbauen, etwa <tt>L_a%=</tt>, <tt>L_b%=</tt>, etc. Das <tt>"%="</tt> wird durch eine für die Übersetzungseinheit und den Code-Schnippsel eindeutige Zahl ersetzt. Die obigen Sequenzen könnten also z.B. umgesetzt werden als <tt>L_a14</tt> und <tt>L_b14</tt>, wenn sie im gleichen Schnippsel stehen.

Etwas bequemer ist die Verwendung einer Ziffer als Label. Beim Sprung gibt man direkt hinter der Ziffer an, in welche Richtung das Label gesucht wird. Ist das Label <tt>''n''</tt>, dann sucht und springt
*<tt>''n''b</tt> zurück (backward)
*<tt>''n''f</tt> nach vorne (forward)

Es wird zum nächsten auffindbaren Label in der angegebenen Richtung gesprungen.

===Bits zählen===
Dieses Assembler-Schnippsel zählt die Anzahl der gesetzten Bits in einem Byte <tt>eingabe</tt>. Die Eingabe wird nach rechts ins Carry geschoben, und das Carry zum Ergebnis dazu addiert.
<pre>
static inline unsigned char count_bits (unsigned char eingabe)
{
unsigned char count;

asm volatile (
"clr %0" "\n"
"0:" "\n\t"
"lsr %1" "\n\t"
"adc %0, __zero_reg__" "\n\t"
"tst %1" "\n\t"
"brne 0b"
: "=&r" (count), "=r" (eingabe)
: "1" (eingabe)
);

return count;
}
</pre>
Damit kann man sich ein Parity bauen:
#define parity(x) (count_bits(x) & 1)
und hätte eine schlankere (aber etwas langsamere) Parity-Implementierung als in <tt>avr/parity.h</tt>. Ein
if (parity(foo))
...
wird in Assembler dann zu (<tt>r24 = eingabe</tt>, <tt>r25 = count</tt>):
<pre>
lds r24,foo
/* #APP */
clr r25
0:
lsr r24
adc r25, __zero_reg__
tst r24
brne 0b
/* #NOAPP */
sbrs r25,0
rjmp .L1
...
</pre>

=Bugs=
* Um das Sonderzeichen <tt>"%~"</tt> benutzen zu können, muss bei parameterlosen Inline Assembler dem Template ein Doppelpunkt folgen:
:<pre>asm volatile ("%~call some_function" :);</pre>
=Quellen=
* Doku zur avr-libc
* Doku zu avr-gcc
* Quellen von gcc

=Siehe auch=
* [[AVR Assembler Einführung]]
* [[:Kategorie:Quellcode Assembler|Quellcode Assembler]]
* [[Sourcevergleich#GCC (Assembler einfügen)]]
* [[avr-gcc]]

[[Kategorie:Microcontroller]]
[[Kategorie:Software]]
[[Kategorie:Grundlagen]]
[[Kategorie:Quellcode Assembler AVR]]
[[Kategorie:Quellcode C]]

AVR Assembler Einführung

2006-12-03T12:46:43Z

Heigro: Typo

==AVR Assembler Einführung==
Es gibt mehrere Gründe, sich mit dem AVR-Assembler zu beschäftigen:
* reines Interesse
* Man hat eben keinen anderen Compiler, Bascom kostet ja was und GCC-C kann man möglicherweise genausowenig, also warum nicht gleich.
* Endlich Programmieren ohne Sprach-Restriktionen
* (theoretisch) sagenhaft schneller und kurzer Code

Dadurch ergeben sich aber auch verschiedene Haupt-Zielgruppen für eine Einführung. Die eine ist in einer oder mehreren anderen Sprachen durchaus versiert, und möchte endlich auch mal richtig in die Tiefen der Hardware steigen. Die andere ist totaler Neueinsteiger und hat gehört, daß man Micro-Controller am besten mit Assembler programmiert.

Es soll hier nur eine Starthilfe zum Einstieg gegeben werden. Viele Details und Varianten werden hier bei weitem nicht erschöpfend behandelt.

==Unterschiede zu anderen Sprachen==
Man kann Assembler nicht direkt mit anderen Hochsprachen vergleichen. Es ist falsch gesagt Assembler ist viel besser als C, oder C ist viel besser als Assembler.
Hochsprachen haben generell ihren Vorteil in kürzerer (Programmier-) Zeit viel mehr erreichen zu können. Während man in Assembler jedes Detail programmieren muss schreibt man in der Hochsprache was man genau möchte und der Compiler erledigt das dann für einen, indem er den Code dann in Assembler übersetzt.
Der Vorteil liegt also klar auf der Hand, man spart sich eine Menge (unnötiger) Arbeit in dem man schneller sagen kann was man eigentlich machen möchte. Wie das jetzt genau funktioniert und was man dabei beachten muss übernimmt der Compiler.
Da gibts dann aber auch schon den ersten Nachteil. Fängt man mit einer Hochsprache an, braucht man sich hardwaremäßig kaum mit dem µC auseinander zu setzen und weiß deshalb auch nicht genau drüber Bescheid. Funktioniert dann etwas nicht sitzt man auf dem Schlauch.
Die Compiler werden aber immer besser, so kommen immer seltener Fehler zustande.

Ein weiterer Nachteil ist eine Glaubens Frage, da man sich kaum mehr mit der Hardware auseinander setzt und nicht wissen muss wie ein µC eigentlich funktioniert geht die "Kultur" verloren. Man lernt gar nicht zu schätzen was das Ding jetzt eigentlich leistet. Die Ansprüche werden immer höher gesetzt und jeder Aussetzer ist umso schlimmer.

Ein extremes Beispiel:
Ein eisener Geschäftsmann geht nach Spanien und braucht Arbeiter, er schickt einen Gehilfen auf die Suche nach Arbeiter und schickt diese dann aufs Feld arbeiten. Ohne auch nur irgend etwas über deren Kultur zu wissen verlangt er das hart gearbeitet wird.
Doch schon in der ersten Woche gibt es Probleme, die Arbeiter möchten Mittags eine Pause. "Was, eine 3 Stündige Siesta? Seit ihr verrückt? Die in Japan arbeiten die Mittagszeit ja auch durch! Wie kommt ihr auf die Idee 3 Stunden Pause zu machen?"

Vorteile von Assembler sind also dass man weiß, was der µC genau macht (bzw. für Anfänger "was er tun sollte").
Man hat die volle Kontrolle und fast jeder Befehl wird bei einem AVR mit einem Takt ausgeführt.
Man kann immer noch auf eine andere Hochsprache umsteigen, diese beherscht man dann um so besser.

Einziger Nachteil, man muss alles genau definieren, so wie es der µC haben möchte und kann nicht direkt auf fertige funktionen zurück greifen.
Man schafft in der selben Zeit zwar genau so viel Code, der Code macht dann aber weniger als in C.

Bildhaft ist der Unterschied der: Beim Assembler hat man ein weißes Stück Papier (ohne Linien) und ein Alphabet von A-Z. Aus diesen Buchstaben soll man nun erstmal Worte suchen und dann damit einen sinnvollen Text verfassen.

Bei "höheren" Sprachen ist das Papier zumindest mal liniert, und dazu kriegt man auch ein Wörtebuch und die Grammatik. Teile des Textes sind schon vorgeschrieben und ich muß nurmehr bei den ..... Punkten was einsetzen.

Anders kann man auch sagen, Hochsprachen sind wie ein Baukasten, man muss nur nach seinen Bedürfnissen sich die Teile zusammen "stecken", ab und zu fertigt man sich auch eigene Teile. Aber das meiste ist vorgefertigt und nach eigenen Bedürfnissen schnell angepasst.
In Assembler muss man sich alles selber anfertigen, fertige Module gibt es nicht, es sei denn man hat es schon einmal gemacht und zufällig da.

* Daten
Höhere Sprachen kennen alle möglichen Datentypen in allen möglichen Längen, integer, floating point, Strings. Dadurch sind aber auch gleich die möglichen und zulässigen Operationen schon eingeschränkt.

Beim (AVR) Assembler gibt auch einige Datentypen. Sie unterscheiden sich aber nur durch die Größe, d.h. die Anzahl der Bytes, die sie belegen. Es gibt aber keine Einschränkungen bezüglich der Befehle, die man darauf anwenden kann.

* Vor- und Nachteile
Wenn man den Assembler mit höheren Sprachen vergleicht, um vielleicht Vor- und Nachteile herausarbeiten zu können, kommt man schnell drauf, daß in jedem Vorteil für eine der Seiten auch schon der Nachteil drinnen steckt. Was ich beim Assembler an Performance heraushole, weil ich z.B. "Goodies" eines Controllers ausnutze, bezahle ich, wenn ich mir einen anderen kaufe und dann das ganze Programm umbauen muß.

==Installation AVR-Studio==
Die Installation des ATMEL AVR Studios ist herzergreifend einfach.
* Man bekommt von Atmel das AStudio4b01.exe (oder was halt gerade aktuell ist) , das man einfach startet und schon ist es passiert.
* Wenn man nun das Käferchen doppelklickt und startet,
**erzeugt man am besten gleich mal ein neues Project.
**Man wählt den Pfad des Projects, und
**Wenn man seinen Brennadapter im Menü nicht findet, wählt man eben den Simulator und verwendet dann halt das PonyProg, oder was man halt hat.
**avrstudio erzeugt ein leeres Projekt und eine leere Assemblersource, die so heißt wie das Projekt. Das Gewurstel mit der Make-file nimmt uns AvrStudio ab.
==Struktur eines AVR-Maschinenprogrammes==
Bei höheren Sprachen wird diese Struktur vom Compiler/Linker erzeugt, beim Assembler muß man sich selbst darum kümmern.

[[Bild:Asm_Flow.jpg]]

Der Controller beginnt mit der Abarbeitung links oben bei der Programmspeicheradresse 0000. Wenn man Interrupts verwenden will, muß man gleich das nächste Bereich (ISR-Vectoren) überspringen (mit "JMP"). Wenn nicht, kann man sich diese Vektoren aber auch wegdenken.

Man landet so oder so bei den Befehlen, die der Initialisierung dienen (Setzen der Startbedingung). Das ist zumindest die Festlegung des Stack-Pointers, sonst kann man keine "CALLS" oder Interrupts durchführen.

Danach kommt man von oben in die Haupt-Programm-Schleife, die (üblicherweise) immer wieder ohne Ende durchlaufen wird.

Das "End" ist bei Microcontrollern daher auch kaum wirklich notwendig. Wenn es da ist, ist das eine ewige Wiederholung eines einzigen Befehls.

==Source-Code Muster==
Das folgende Codebeispiel ist eine reine Basis-Initialisierung ohne irgendeine erkennbare Funktion. Für den Einstieg ist es am besten, das einfach abzuschreiben, wie es ist, und dann an den bezeichnenten Stellen mit eigenen Befehlen nach und nach zu erweitern.

<pre>
.NOLIST ; List-Output unterdrücken
.INCLUDE <m8def.inc> ; das gibt es für jeden Controllertyp
.LIST ; List-Output wieder aufdrehen
.CSEG ; was nun folgt, gehört in den FLASH-Speicher

;------------------------------------------------------
; Start Adresse 0000
;------------------------------------------------------
RESET:
jmp INIT ; springen nach "INIT"

;------------------------------------------------------
; ISR VECTORS
;------------------------------------------------------
; ..... hier kommen dann die Sprungadressen für die Interrupts rein
; dazu kommen wir noch

.ORG INT_VECTORS_SIZE ; dadurch haben wir für die Vektoren Platz gelassen
INIT:
;------------------------------------------------------
; INITIALIZE
;------------------------------------------------------
ldi r24,high(RAMEND) ;Stack Pointer setzen
out SPH,r24 ; "RAMEND" ist in m8def.inc (s.o.) festgelegt
ldi r24,low(RAMEND) ;
out SPL,r24 ;

;------------------------------------------------------
; eigene Initialisierungen
;------------------------------------------------------
;....
;....
;....

;------------------------------------------------------
; HAUPTSCHLEIFE
;------------------------------------------------------
Hauptschleife:
;.... eigene befehle
;.... eigene befehle
;.... eigene befehle
rjmp Hauptschleife ; immer wiederholen

;------------------------------------------------------
; ENDE
;------------------------------------------------------
Ende:
rjmp Ende
</pre>
===Der Ablauf der Übersetzung===
Der Assembler ist ja selbst auch nur ein Programm und zu Beginn recht spartanisch ausgestattet: Er hat einen Daten-Buffer zur Verfügung, in den er den Maschinencode hineinschreiben soll, einen Pointer (Zeiger) dazu, damit er immer weiß, wo er grad ist, und eine allgemeine Tabelle, wo er Texte mit Zahlen verknüpfen kann. Alles ist zu Beginn leer bzw. auf NULL.
Mit diesen Voraussetzungen fängt er an, unseren Source-Text zeilenweise zu lesen. Und in jeder Zeile (die nicht leer ist) erwartet er eine Anweisung, was zu tun ist
====Assembler Direktiven/Präprozessor====
Das sind Anweisungen an den Assembler selbst und erzeugen keine Maschinenbefehle. Im obigen Source-Beispiel sind einige enthalten.
.NOLIST
Normalerweise schreibt der Assembler ja eine Übersetzungsliste. Nach dieser Anweisung läßt er das bleiben
.INCLUDE <m8def.inc> ; das gibt es für jeden Controllertyp
sagt ihm, er soll jetzt erstmal die (text) datei "m8def.inc" lesen und genauso behandeln, als wäre diese Datei mit dem Editor hier reinkopiert worden.
.LIST
Ab nun wird wieder alles in der Übersetzungsliste protokolliert.
.CSEG
was danach folgt, bezieht sich auf den FLASH-Programm-Speicher

Gleich ein Hinweis: Der "AVR Assembler 2" geht dazu über, die C-Syntax für
Präprozessoranweisungen zu verwenden. Diese haben dann als Kennzeichen ein "#" vorangestellt.

====Bemerkungen / Kommentare====
;------------------------------------------------------
Alles, was NACH einem Strichpunkt steht, schreibt er einfach nur in die Übersetzungsliste, sonst macht er nix.
====Label (Sprungmarke)====
RESET:
Was gleich ganz links in der Zeile beginnt (und mit einem Doppelpunkt abgeschlossen ist) schreibt er einfach in die genannte Tabelle und den momentanen Wert des Instruction Pointers (IP) dazu. Sonst hat das im Moment keine weitere Bedeutung. Natürlich, wenn er den gleichen Text schon mal hatte, gibt es eine Fehlermeldung, denn '''ein Label muss eindeutig sein'''

====Commands====
jmp INIT ; springen nach "INIT"
Alles, was nicht ganz links steht und auch nix anderes ist, betrachtet der Assembler als "Command". Normalerweise ist das eben eine AVR-Instruktion aus dem "Instruction Set". Hier ist das "JMP", also im Programm einfach woanders weitermachen. Gut, aber wo ? Der Rechner braucht nun unbedingt eine Zahl, denn "INIT" sagt ihm ja nichts. Also sieht er nun in der Tabelle nach, ob er den Text "INIT" schon mal hatte. Hatte er nicht, den zu der Stelle weiter hinten, wo "INIT:" als Sprungmarke steht (s.o) ist er ja noch garnicht gekommen.

Ich kann leider nicht genau sagen, welche Strategie der AVR-Assembler nun anwendet, dazu gibt es keine Doku. Manche Assembler lesen erstmal überhaupt nur den Sourcetext von vorn bis hinten durch, um alle "Sprungmarken" zu sammeln (Pass I) und fangen dann nochmal von vorne an (Pass II), diesmal mit schon gefüllter Tabelle. Andere machen das etwas gefinkelter. Ist uns aber eigentlich egal.

Jedenfalls findet er letztlich den Text "INIT" und daneben steht die Nummer der Speicherstelle, wo wir eben "INIT:" hingeschrieben haben. Und nun schreibt der Assembler also den Maschinencode für "JMP" in den Buffer und dazu die Zahl aus der Tabelle. Das war mal ein Befehl, also addiert er auf seinen Zeiger eins drauf und ist mit diesem Befehl fertig.

====ORG / JMP====
Das, was für den Controller beim Ablauf dann ein "JMP" ist, ist das ".ORG" für den Compiler. Wenn also bislang der Assembler den FLASH-Speicher von 0 - nn mit Befehlen befüllt hat, macht er durch
.ORG INT_VECTORS_SIZE
mit der Stelle weiter, die er über die gleiche Tabelle unter "INT_VECTORS_SIZE" gefunden hat. Dieser Tabelleneintrag, genauso wie "RAMEND" an anderer Stelle, entsteht aus der Datei "m8def.inc". Wie im vorliegenen Fall macht man diese "Assembler-Jumps", um Speicherstellen freizuhalten.

==Merkwürdiges==
===Befehlsadressen / Byteadressen ===
[[Atmel Controller Mega16 und Mega32#Maschinen-Code|Ein Maschinenbefehl besteht aus maximal drei, bit-mäßig verschachtelten Teilen]]. Die meisten Befehle brauchen dafür genau 16 Bit (also zwei Byte), manchmal reicht das nicht, da gehören dann nochmal 16 Bit dazu. Kleiner als 16 Bit ist aber keiner. Aus diesem Grund wäre es natürlich sinnlos, Adressen für Befehle in Bytes auszudrücken, wenn es eh immer Vielfache von 2 sein müssen, das kleinste Bit einer solchen Adresse wäre ja immer null.

Also adressiert man Commands in "Worten" von 16 - Bit bzw. 2 Bytes

Beim Ablegen eines Labels (Sprungmarke) werden also Wortadressen in der Tabelle angelegt. Solange der Wert auch als Befehls-Adresse verwendet wird (z.B. "JMP ''Label''"), braucht das nicht zu kümmern, denn genauso will es der AVR ja dann auch haben. '''Wenn dort aber Daten stehen''' und wir wollen diese adressieren, müssen wird '''den Wert mal 2 nehmen''' (oder einmal nach links schieben, was dasselbe ist), sonst landen wir im Nirwana.
===3 ist nicht gleich 3 ===
Eine Zahl bedeutet also bei der Maschinensprache unter Umständen ganz was anderes, je nachdem, in welchem Zusammenhang sie verwendet wird. Bei allen Befehlen, die nur für die Register 16 - 31 gehen, steht im Maschinencode für das Register 16 nicht 16 drin, sondern 0. die "16" addiert er dann bei der Befehlsausführung drauf (für den Techniker: er braucht ja nur das Bit 24 hochzuziehen)
===GPR ist nicht gleich GPR===
Was auch beim Einstieg leicht irritieren kann ist der Umstand, daß die 32 sogenannten "'''G'''eneral '''P'''urpose '''R'''egister" irgendwie so gar nicht generell und gleich sind. Manche Befehle kann ich mit allen 32 Registern machen, einige nur mit R16-R31, andere von R24 aufwärts und dann sind da noch R26 bis R31, die heissen dann manchmal auch noch X, Y und Z
===SFR ist gar nicht gleich GPR===
'''S'''pecial '''F'''unction '''R'''egister sind überhaupt seltsam, die meisten GPR-Befehle gehen da gleich garnicht, dafür gibt es andererseits ein paar Bit-Manipulationen, die gehen wiederum nur mit diesen. Dann gibt es auch Bit-Abfragen, die gehen da wie dort und bewirken auch das Gleiche, aber dafür heissen sie dann anders.
===Assembler-Befehle===
Viele dieser Probleme nimmt uns der Assembler ab, viele aber nicht. Dort erscheinen die Instruktionen immer so
{| {{Blauetabelle}}
| ''' '''
| '''CMD'''
| '''ARG1'''
| '''ARG2'''
|}
wobei die Argumente 1 u. 2 optionell, d.h. bei Bedarf erscheinen. Command ist natürlich immer da.
Trotz der Hilfe des Assemblers durch "Warnings" und "Errors" ist bei den Argumenten aber immer Vorsicht geboten. Wir haben gehört, daß Arg 1 und Arg 2 im Grunde einfach nur zwei Zahlen sind, die dann zusammen mit dem Command-Code zum Maschinenbefehl werden. Wenn es dem Assembler also auch nur irgendwie gelingt, aus dem, was wir da hinschreiben, Zahlen zu machen die er umwandeln kann, nimmt er sie auch.

===Zwischenbilianz===
Einiges dieser sonderbaren Dinge lassen sich leicht erklären, manche schwer, manche mangels Unterlagen darüber garnicht. Deswegen versuch ich es hier auch gleich garnicht.

So oder so sind es Fakten, an die man sich am besten einfach gewöhnt. Das scheint und ist am Anfang sicher schwer, solange man noch mit den Befehlen einzeln kämpft. RISC-Befehle werden aber erst in bestimmten Gruppierungen überhaupt wirklich sinnvoll, und durch diese sich immer wieder wiederholenden Gruppen wird es sehr schnell leichter.

Beim Briefe schreiben denkt man ja auch nicht in Buchstaben, das wäre mühsam, sondern in Worten oder in ganzen Sätzen.

==Load & Store==
Die meisten Befehle für den AVR laufen nach dem Load & Store (Laden und Speichern) Prinzip ab. Das heißt, die Daten werden zuerst aus dem SRAM-Speicher (oder den I/O bzw. SFR Registern) in die allgemeinen Register (GPR) geladen, dort verarbeitet, und danach wieder in den SRAM oder die SFR zurückgestellt.

[[Bild:Asm_cmd.jpg]]

Das ist natürlich eine recht allgemeine Darstellung, aber es hilft, das Instruction Set des AVR schon ein wenig besser zu verstehen.

Es bedeutet, um z.B. ein Byte aus der einen Ecke des SRAM in eine andere zu kopieren, brauchen wir wenigstens 2 Maschineninstruktionen, einmal Load und einmal Store. Und wenn wir was an dem Byte ändern wollen, kommt diese Befehle natürlich dazu.

Es gibt zu (fast) jeder Art "Load"-Befehl ein Äquivalent als "Store", und zum Finden genügt es meist, statt "L" an der selben Stelle ein "S" zu nehmen.
<pre>
LDS GPR, adresse ; lade das Byte von der Adresse in ein GPR
STS adresse, GPR ; speichere den Inhalt von GPR in der Adresse
</pre>
Wenn es um die I/O Register (SFR) geht:
<pre>
IN GPR, I/O-Register ; GPR <-----I/O Register
OUT I/O-Register, GPR ; I/O Register <---- GPR
</pre>
Für feste Werte (Literals) gibt es natürlich keine Store-Variante, denn diese Werte stehen ja im FLASH (Programm) Speicher, und da kann man nicht einfach einzelne Bytes verändern.
<pre>
LDI GPR, wert
</pre>

===Beispiel===

An PORTC haben wir (mit Vorwiderständen) ein paar LED angeschlossen. Und die sollen einfach nur zeigen, welche 0-er und 1-er am PORTB anliegen.
<pre>
; Eigene Initialisierungen
LDI R24, 0 ; der wert "0" ins allgemeine Register R24
OUT DDRB, R24 ; das kommt ins Controll-register f. PortB
; dadurch sind diese PINs als INPUT festgelegt
LDI R24, 255 ; der wert "255" = FF ins allgemeine Register R24
OUT DDRC, R24 ; das kommt ins Controll-register f. PortC
; dadurch ist das Port auf OUTPUT gestellt
</pre>

<pre>
; Eigene Befehle (in der Hauptschleife)
IN R24, PINB ; die Bits vom PortB ins allgemeine Register R24
OUT PORTC, r24 ; schreiben wir nach PortC
; wo ein 1-er ist, leuchtet nun die LED
</pre>

Wenn wir diese Befehle in das Programm-Schema oben einfügen, haben wir also das erste Assemblerprogramm schon geschrieben.
====Programm-Map====
Eine interessanter Output, wenn wir dieses Programm mit F7 übersetzen lassen, ist die Map-File. Sie ist ein Abbild der oben genannten "Text <--> Adresse"-Tabelle

(gekürzt)
<pre>
AVRASM ver. 2.0.28 D:\avr_c\avrstudio\Dokutest\Dokutest.asm Sat Dec 10 11:23:45 2005
....
EQU sram_start 00000060
EQU sram_size 00000800
EQU ramend 0000085f
......
EQU sph 0000003e
EQU spl 0000003d
EQU portb 00000018
EQU ddrb 00000017
EQU pinb 00000016
EQU portc 00000015
EQU ddrc 00000014
EQU pinc 00000013
EQU int_vectors_size 0000002a
CSEG reset 00000000
CSEG init 0000002a
CSEG hauptschleife 00000032
CSEG ende 00000035
</pre>
Wir finden darin alle Sprungadressen und alle sonstigen Werte, die wir verwendet haben. Tatsächlich in den Maschinencode eingesetzt werden vom Assembler immer die Zahlen, die daneben stehen

===Pointer-Register===
In vielen Fällen ist es nicht sinnvoll, für Load & Store explizit jedesmal die Speicheradresse dazuschreiben zu müssen. Es können auch die Pointer Register X, Y und Z verwendet werden. Das sind die Register
R26:R27 = X
R28:R29 = Y
R30:R31 = Z
Da wir ja oft mehr Speicher haben als 256 Byte, werden immer zwei Register zusammengefaßt und können dadurch die Bereiche 0 - 65535 abdecken (64k). Gut, aber wie kriegen wir so große Zahlen da rein ? Wir haben ja nur einen 8-Bit Processor und nicht 16.

Wir müssen also die Adresse 8-Bit-weise übergeben, aber der Assembler hilft uns ja dabei.
<pre>
LDI R26, LOW(Adresse) ; R28 für "Y" u. R30 für "Z"
LDI R27, HIGH(Adresse) ; R29 für "Y" u. R31 für "Z"
</pre>
Mit diesem "LOW" und "HIGH" teilt uns der Assembler die Adresse genau in die richtigen 8-Bit Portionen, die wir also so in den "X" Pointer laden können.

Noch eine Hilfe gibt es: Wir können, besser zu merken, auch schreiben:
<pre>
LDI XL, LOW(Adresse) ; YL für "Y" u. ZL für "Z"
LDI XH, HIGH(Adresse) ; YH für "Y" u. ZH für "Z"
</pre>
Also "LOW" für "L" und "HIGH" für "H"

====Indirekte Adressierung====
Mit den Pointer-Register kann man also Indirekte Adressieren(=einmal um die Ecke). Statt:
<pre>
LDS GPR, adresse ; lade das Byte von der Adresse in ein GPR
</pre>
Schreiben wir
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
LD GPR, X ; '''Indirekt''': lade das Byte, wo der Pointer X hinzeigt
</pre>
beziehungsweise
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
ST X, GPR ; '''Indirekt''': speichern, wo der Pointer X hinzeigt
</pre>
Warum sollte man sowas kompliziertes tun ? Nun, zum Beispiel dann,
* wenn man an einer Stelle im Programm die Adresse festlegt, aber ganz woanders braucht (Subroutinen)
* wenn man für mehrere Folge-Befehle die gleiche Adresse wieder braucht
* wenn man mit der Adresse (als Zahl) rechnen will

====Post-Increment/Pre-Decrement====
Wenn ich zum Beispiel 4 Byte hintereinander im Speicher auf "0" löschen will
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
LDI GPR, 0
ST X+, GPR ;speichern, wo X hinzeigt, und dann 1 auf X addieren
ST X+, GPR ;das 2.Byte dahinter
ST X+, GPR ;das 3.Byte dahinter
ST X+, GPR ;das 4.Byte dahinter
</pre>
Durch das automatische Addieren brauche ich nichts weiter zu tun. Als Gegenstück dazu kann man auch jedesmal 1 abziehen lassen, das aber immer '''vorher'''
<pre>
ST -X, GPR ;1 von X abziehen und dann speichern, wo X hinzeigt
</pre>

All das gibt's für X, Y und Z. Es geht aber immer nur
* Load & Store und '''dann''' addieren
* '''erst''' subtrahieren und '''dann''' Load & Store
Diese Kombinationen werden einfach am häufigsten gebraucht

====Displacement====
Für die beiden Pointer Y und Z kann man auch mit Displacement arbeiten
<pre>
LDD GPR, Y+4 ; wo Y hinzeigt, aber 4 Byte dahinter
</pre>

==Welches Register ?==
Bei den Load & Store Befehlen könnten als GPR alle 32 Allgemeinen Register beliebig verwendet werden, um das entsprechende Byte aufzunehmen oder abzugeben. Aber als Zwischenspeicher oder Arbeitsregister ist es am besten, Registern wie r26->r31, die möglicherweise als Pointer gebraucht werden, eher auszuweichen.

Wird das Assemblerprogramm durch inline oder libraries in eine Hochsprache
eingebunden, muß man bei sich natürlich an die Register-Konventionen dieser
Umgebung halten.

Schreibt man ein "stand-alone" Programm, kann (und sollte) man sich seinen eigenen
Konventionen und Regeln schaffen. Das ist das, was der Assembler-Fan so liebt.

==Benutzerdaten==
Daten wie Variable oder Felder werden üblicherweise im SRAM abgelegt und (s.o) von dort auch geholt. Bei allen Compilern und natürlich auch beim Assembler können zum Programmierzeitpunkt nur die Adressen davon festgelegt werden, aber keine Inhalte. Erst zur Laufzeit des Programmes kommen hier Werte rein. Manche Compiler gaukeln es zwar vor, aber (ein C-Beispiel):
<pre>
char MeinName[] = "Sepp Meier"
</pre>
bewirkt in Wirklichkeit drei Dinge: Im SRAM wird die nächste, noch nicht benutzte Adresse dem Text "MeinName" in der oben genannten Tabelle abgelegt, der String "Sepp Meier" wird im FLASH Programmspeicher bereitgestellt, und es wird eine Transfer-Routine generiert, die beim tatsächlichen Start des fertigen Programmes diesen String in das Feld "MeinName" transferiert.

Im Assembler ist es eben genauso: Wir können durch die Anfangsadressen und einen Namen dazu Felder festlegen, die dann zur Laufzeit benützt werden. Mehr eigentlich nicht. Und erst, wenn wir Befehle schreiben, die diese Daten verwenden, ergibt sich daraus ein Datentyp. Vorher sind das einfach nur Bytes.

Das ist bei Hochsprachen anders: Schon in der Source legen wir durch verschiedene Angaben den Datentyp (char, integer, etc.) fest und daraus entscheidet dann der Compiler, welche Maschinen-Instruktionen er dafür verwenden wird. Wir können das nurmehr eingeschränkt beeinflussen.

===Daten im SRAM===
<pre>
.DSEG ; Das ist eine Datensegment, d.h. es werden SRAM-Adressen festgelegt
CharBuf: .byte 24
OtherData: .byte 4
....
</pre>
'''Anmerkung:''' Standardgemäß beginnt der Assembler mit der kleinsten SRAM Adresse. Bei den meisten AVRs ist das die tatsächliche Byte-Adresse 0x0060 (d.i. 96 dezimal).
[[Atmel_Controller_Mega16_und_Mega32#Adressen_Mapping|Siehe Adress-Mapping]]

Dadurch, daß wir geschrieben haben ".byte 24" bestimmen wir, daß als nächste Datenadresse automatisch dann 96 + 24 = 120 gilt. Also ist mit "OtherData" dann 0x0078 (dez. 120) verknüpft.

'''Noch eins:''' Wir haben ja gesagt, für den Assembler ist alles letztlich eine Zahl. Wir können daher auch damit rechnen. Wenn wir also die "24" nicht selbst wo hinschreiben wollen, verwenden wir einfach den Ausdruck
LDI R10 , Otherdata - CharBuf
und laden damit das Register 10 mit der Zahl 24

===Daten im FLASH (Literale)===
Literale sind Werte, die schon in der Source festgelegt werden können. Das geht im Prinzip ähnlich, nur müssen wir nun auch Datentypen festlegen
<pre>
OneByte: .db 1 ; ein byte mit dem inhalt 0x01
MeinName: .db "Sepp Meier" ; mehrere Bytes mit Text
OneWord: .dw 1,2 ; zwei WORDs (16 Bit) mit dem inhalt 0x0001 u. 0x0002
....
</pre>

Diese Definitionen können wir auch direkt in den Programmcode reinmischen. Wir müssen aber natürlich schauen, daß der AVR zum Laufzeitpunkt nicht versucht, diese Zeichen als Befehl auszuführen.

===Daten im EEPROM (ERAM)===
genauso geht es, wenn man für den EEPROM feste Werte vorgeben will:
<pre>
.ESEG ; Das ist ein EEPROM-Segment
OneByte: .db 1 ; ein byte mit dem inhalt 0x01
MeinName: .db "Sepp Meier" ; mehrere Bytes mit Text
OneWord: .dw 1,2 ; zwei WORDs (16 Bit) mit dem inhalt 0x0001 u. 0x0002
....
</pre>

==Verzweigungen==
Es gibt zwei Arten, bedingte Programm-Sprünge zu formulieren:
* Durch irgendwelche Befehle, meistens durch Vergleichsoperationen, erst die Bits im Statusregister (SREG) zu setzen, und diese Status-Bits abzufragen und je nachdem einen Programmsprung durchzuführen oder nicht.
* Man kann aber auch abhängig von Datenbits in GPRs und SFRs den Folgebefehl überspringen (Skippen) lassen. Dieser Folgebefehl kann, muß aber nicht, ein Sprung- oder Callbefehl sein.

==Zusammenfassung==
Da dieser Artikel kein Assembler Tutorial sein kann und soll, soll hier auf die "eigentlichen" Instruktionen nicht eingegangen werden. Ich wollte nur versuchen, die "Denkweise" des Assembler und der AVR-Micros ein wenig näherzubringen und einige ermuntern, doch die ersten Operationen direkt am offenen Herzen des Kontrollers zu wagen.

In manchen Fällen habe ich aber sicher einige Leser endgültig verschreckt.

==Noch ein Tip==
Gut abgeschrieben ist am Anfang besser als schlecht ausgedacht. Gerade die verschiedenen Geräte-Initialisierungen (SFR) in den zahlreichen GCC Codeschnipsel können fast direkt abgeschrieben werden (Baudrate, Input/Output, etc), da der C-Compiler das ja auch nicht anders machen kann.

==Autor==
[[User:PicNick|PicNick]]

==Weblinks==
[http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11488 Ausführlicher Foren-Beitrag zum Thema Assembler-Programmierung] – Lang aber lehrreich
==Siehe auch==
*[[AVR]]
*[[Sourcevergleich]]
*[[GNU Assembler]]
*[[Assembler_Einf%C3%BChrung_f%C3%BCr_Bascom-User|Assembler Einführung für Bascom-User]]
[[Kategorie:Microcontroller]]
[[Kategorie:Robotikeinstieg]]
[[Kategorie:Software]]
[[Kategorie:Quellcode Assembler AVR]]

Avr-gcc

2006-12-01T07:56:07Z

Heigro: Typo

'''avr-gcc''' ist ein freier C-[[Compiler]], mit dem man C-Programme zu ausführbaren Programmen übersetzen kann, die auf [[Microcontroller]]n der [[AVR]]-Familie lauffähig sind.
An Sprachen versteht avr-gcc sowohl C als auch [[#C%2b%2b|C++]].
Neben Standard-C bzw. ANSI-C versteht avr-gcc auch GNU-C, das etwas mehr Möglichkeiten und kleinere Spracherweiterungen bietet.

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

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

=How to Read=

Dieser Artikel bespricht avr-gcc Version 3.x. Er ist kein C-Tutorial und kein AVR-Handbuch – das würde den Umfang des Artikels bei weitem sprengen. Es gibt einen Unterartikel, der [[avr-gcc/Interna|Interna von avr-gcc]] zusammenfasst.

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

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

In den [[:Kategorie:Quellcode C|C-Codebeispielen]]
befindet sich das ausführlichere Beispiel "[[Hallo Welt für AVR (LED blinken)]]",
das nur eine [[Diode#Lumineszenzdiode|LED]] blinkt und zeigt,
wie ein kleines Projekt mit avr-gcc compiliert werden kann.

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

=Benutzer-Schnittstelle=

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

Im einfachsten Fall sieht ein Aufruf von avr-gcc also so aus:
> avr-gcc
Dabei das '<tt>></tt>' nicht mittippen, und ein ENTER am Ende der Zeile drücken.
Die Antwort bei korrekter Installation ist dann
avr-gcc: no input files
Was bedeutet: das Programm avr-gcc wurde vom Betriebssystem gefunden und konnte/durfte gestartet werden. Dann gibt avr-gcc eine Fehlermeldung aus und beendet die Ausführung, weil er keine Eingabedatei(en) bekommen hat was ja auch stimmt. Soweit ist also alles in Butter.

Um eine C-Datei <tt>foo.c</tt> mir avr-gcc optimiert zu einem lauffähigen elf-Programm <tt>foo.elf</tt> für einen [[ATmega32]] zu compileren, würde man angeben
> avr-gcc -O2 -mmcu=atmega32 foo.c -o foo.elf
Hat man seine Quellen auf zwei oder mehre Dateien verteilt, geht es analog:
> avr-gcc -O2 -mmcu=atmega32 foo.c foo2.c -o foo.elf

Will man nur eine Objekt-Datei erstellen (nur compilieren, nicht linken), dann geht das wie folgt. Das kann günstig sein bei grösseren Projekten, wenn man das Projekt neu erzeugen will, aber nur in einer Quelldatei was geändert hat. Oder wenn das Objekt in einer Bibliothek landen soll.
> avr-gcc -O2 -c -mmcu=atmega32 foo.c -o foo.o

Die ausführbare Gesamtdatei <tt>foo_all.elf</tt> erhält man dann, indem alle Objekte zusammenlinkt:
> avr-gcc -mmcu=atmega32 foo.o foo2.o foo3.o -o foo_all.elf

Um die ausführbare Datei in das oft verwendete Intex-HEX-Format umzuwandeln (einmal fürs Programm, einmal für ein Abbild des [[EEPROM]]s) gibt man an:
> avr-objcopy -O ihex -j .text -j .data foo_all.elf foo_all.hex
> avr-objcopy -O ihex -j .eeprom --change-section-lma .eeprom=0 foo_all.elf foo_all_eeprom.hex

----

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

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

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

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

==Maschinenspezifische Optionen für avr-gcc==
Maschinenabhängige Optionen beginnen immer mit '''-m'''
;-mmcu=xxx: Festlegen des Targets (Zielsystem/Controller), für das Code generiert werden soll. Je nach Target muss avr-gcc unterschiedliche Instruktionen verwenden und andere Startup-Dateien (<tt>crtxxx.o</tt>) einbinden. avr-gcc setzt spezielle Defines, um auch in der Quelle zwischen den Targets unterscheiden zu können, falls das notwendig sein sollte:
:{| border="0" cellpadding="0" cellspacing="0"
|
<pre>
#ifdef __AVR_AT90S2313__
/* Code fuer AT90S2313 */
#elif defined (__AVR_ATmega8__) || defined (__AVR_ATmega32__)
/* Code fuer Mega8 und Mega32 */
#else
#error Das ist noch nicht implementiert für diesen Controller!
#endif
</pre>
|}

Zwar gibt es für alle AVR-Derivate die <tt>avr/io.h</tt>, aber die AVR-Familien unterscheiden sich in ihrer Hardware; z.B. darin, wie I/O-Register heissen oder wie Hardware zu initialisieren ist. Diese Abhängigkeit kann man in unterschiedlichen Codestücken aufteilen und wie oben gezeigt bedingt übersetzen. Dadurch hat man Funktionalitäten wie <tt>uart_init</tt> auf unterschiedlichen Controllern und wahrt den Überblick, weil nicht für jede Controller-Familie eine extra Datei notwendig ist.
{|
|- valign="top"
|
:{| {{Blauetabelle}}
|+ '''AVR classic, <= 8 kByte'''
|- {{Hintergrund1}}
!|mcu || Builtin define
|-
|avr2 ||<tt>__AVR_ARCH__=2</tt>
|-
|[[AT90S2313|at90s2313]] ||<tt>__AVR_AT90S2313__</tt>
|-
|at90s2323 ||<tt>__AVR_AT90S2323__</tt>
|-
|at90s2333 ||<tt>__AVR_AT90S2333__</tt>
|-
|at90s2343 ||<tt>__AVR_AT90S2343__</tt>
|-
|attiny22 ||<tt>__AVR_ATtiny22__</tt>
|-
|attiny26 ||<tt>__AVR_ATtiny26__</tt>
|-
|at90s4414 ||<tt>__AVR_AT90S4414__</tt>
|-
|at90s4433 ||<tt>__AVR_AT90S4433__</tt>
|-
|at90s4434 ||<tt>__AVR_AT90S4434__</tt>
|-
|at90s8515 ||<tt>__AVR_AT90S8515__</tt>
|-
|at90c8534 ||<tt>__AVR_AT90C8534__</tt>
|-
|at90s8535 ||<tt>__AVR_AT90S8535__</tt>
|-
|at86rf401 ||<tt>__AVR_AT86RF401__</tt>
|}
| 
:{| {{Blauetabelle}}
|+ '''AVR classic, > 8 kByte'''
|- bgcolor="#ccccff"
! |mcu ||Builtin define
|-
|avr3 ||<tt>__AVR_ARCH__=3</tt>
|-
|atmega103 ||<tt>__AVR_ATmega103__</tt>
|-
|atmega603 ||<tt>__AVR_ATmega603__</tt>
|-
|at43usb320 ||<tt>__AVR_AT43USB320__</tt>
|-
|at43usb355 ||<tt>__AVR_AT43USB355__</tt>
|-
|at76c711 ||<tt>__AVR_AT76C711__</tt>
|}
|}

----

{|
|- valign="top"
|
:{| {{Blauetabelle}}
|+ '''AVR enhanced, <= 8 kByte'''
|- bgcolor="#ccccff"
!|mcu || Builtin define
|-
|avr4 ||<tt>__AVR_ARCH__=4</tt>
|-
|[[Atmel Controller Mega8|atmega8]] ||<tt>__AVR_ATmega8__</tt>
|-
|atmega8515 ||<tt>__AVR_ATmega8515__</tt>
|-
|atmega8535 ||<tt>__AVR_ATmega8535__</tt>
|}
|
:{| {{Blauetabelle}}
|+ '''AVR enhanced, > 8 kByte'''
|- bgcolor="#ccccff"
!|mcu ||Builtin define
|-
|avr5 ||<tt>__AVR_ARCH__=5</tt>
|-
|[[Atmel Controller Mega16 und Mega32|atmega16]] ||<tt>__AVR_ATmega16__</tt>
|-
|atmega161 ||<tt>__AVR_ATmega161__</tt>
|-
|atmega162 ||<tt>__AVR_ATmega162__</tt>
|-
|atmega163 ||<tt>__AVR_ATmega163__</tt>
|-
|atmega169 ||<tt>__AVR_ATmega169__</tt>
|-
|[[Atmel Controller Mega16 und Mega32|atmega32]] ||<tt>__AVR_ATmega32__</tt>
|-
|atmega323 ||<tt>__AVR_ATmega323__</tt>
|-
|[[ATMega64|atmega64]] ||<tt>__AVR_ATmega64__</tt>
|-
|[[Atmel Controller Mega128|atmega128]] ||<tt>__AVR_ATmega128__</tt>
|-
|at94k ||<tt>__AVR_AT94K__</tt>
|}
|}

----

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

----

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

=Dynamische Speicherallokierung=

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

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

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

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

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

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

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

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

{{comment|Mach was mit p[0] ... p[num_data-1]}}
...
}

=C++=

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

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

Weiterhin unterliegt der Einsatz von C++ je nach Compiler/Lib-Version bestimmten Einschränkungen:
*Einer kompletten C++ Implementierung fehlt die Unterstützung durch die <tt>libstdc++</tt>, dadurch fehlen Standardfunktionen, -Klassen und -Templates
* Die Operatoren <tt>new</tt> und <tt>delete</tt> sind nicht implementiert, ihre Verwendung führt zu unauflösbaren externen Referenzen (Linker-Fehler)
*Nicht alle Header sind C++-sicher und müssen in <tt>extern "C" {...}</tt> eingeschlossen werden.
*Exceptions werden nicht unterstützt und müssen via <tt>-fno-exceptions</tt> abgeschaltet werden, oder der Linker beschwert sich über eine unauflösbare externe Referenz zu <tt>__gxx_personality_sj0</tt>.

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

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

#if defined (__cplusplus)
extern "C" {
#endif {{comment|__cplusplus}}

SIGNAL (SIG_NAME)
{
{{comment|machwas}}
}

INTERRUPT (SIG_NAME)
{
{{comment|mach was}}
}

#if defined (__cplusplus)
}
#endif {{comment|__cplusplus}}
<tt>__cplusplus</tt> ist ein Standard [[avr-gcc/Interna#Builtin Defines|GCC-Builtin-Define]].

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

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

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

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

===Zugiff auf Bytes und Worte===
For den Zugriff auf die SFRs gibt es Defines über den Include
#include <avr/io.h>
Abhängig vom eingestellten Controller werden denn Defines eingebunden, über die auf SFRs wie auf normale Variablen zugegriffen werden kann. Die Namen der Defines sind i.d.R. die gleichen wie im AVR-Manual, also z.b. <tt>SREG</tt> für das Prozessorstatus-Register SREG:
#include <avr/io.h>

...
{{ccomment|SREG lesen}}
uint8_t sreg = SREG;
...
{{ccomment|SREG schreiben}}
SREG = sreg;

Für einen Überblick über die eingebundenen Defines und kann ein Blick in den Controller-spezifischen Header hilfreich sein. Dieser befindet sich in
:<tt> <GCC_HOME>/avr/include/avr/io****.h</tt>
z.B. <tt>iom32.h</tt> für einen [[ATmega32]].

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

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

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

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

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

Etwas anders sieht der Code aus, wenn die Bits einzeln gesetzt werden und das Register im bitadressierbaren Bereich liegt (SRAM <tt>0x20</tt> bis <tt>0x3f</tt> resp. I/O <tt>0x0</tt> bis <tt>0x1f</tt>):
<pre>
// Ports B_0 und B_1 als Ausgang
DDRB |= (1<<PB0);
DDRB |= (1<<PB1);
</pre>
erzeugt
<pre>
b8 9a sbi 0x17, 0
b9 9a sbi 0x17, 1
</pre>

Um Bits zu löschen, erzeugt man eine Maske, die an der betreffenden Stelle eine  0 hat:
<pre>
// Ports B_2 als Eingang
DDRB &= ~(1<<PB2);
</pre>

{{FarbigerRahmen|
Auch hier ist zu beachten, daß es Probleme geben kann, wenn nicht atomarer Code erzeugt wird, weil der AVR-Befehlssatz nicht mehr hergibt:
<pre>
// toggle PORT B_0: wechseln 0 <--> 1
PORTB ^= (1<<PB0);
</pre>
ergibt
<pre>
88 b3 in r24, 0x18
; Wenn hier ein Interrupt auftritt, in dessen ISR PORTB verändert wird,
; dann wird die Änderung durch die letzte Instruktion wieder überschrieben!
91 e0 ldi r25, 0x01
; dito
89 27 eor r24, r25
; dito
88 bb out 0x18, r24
</pre>
}} 

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

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

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

==Interrupts==

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

Bitte beachte auch die Hinweise zu den [[#Inkompatibilität|Inkompatibilität]]en von avr-gcc!
<pre>
#include <avr/io.h>
#include <avr/signal.h>

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

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

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

{{FarbigerRahmen|
Die Schreibweise des Signal-Names muss genau die sein wie im Header, das schliesst auch Leerzeichen ein! Nicht alle GCC-Versionen bringen Fehler/Warnung, wenn die Schreibweise nicht stimmt.
SIGNAL (SIG_OUTPUT_COMPARE1A ) // !!! Macht NICHT das, was man will (Blank am Ende)!!!
}}

;<tt>SIGNAL</tt>: Mit Ausführung einer ISR deaktiviert die AVR-Hardware die Interrupts, sodaß die ISR nicht durch andere Interrupt-Anforderungen unterbrochen wird. Beim Verlassen der ISR werden Interrupts wieder aktiviert. Tritt während der ISR ein IRQ auf, wird diese erst nach Beenden des ISR-Codes ausgeführt. Der Interrupt geht also nicht verloren. Zwischen zwei ISRs wird zusätzlich mindestens ein Befehl des normalen Programm-Codes abgearbeitet.
;<tt>INTERRUPT</tt>: Früh im ISR-Prolog werden mit <tt>sei</tt> die von der AVR-Hardware temporär deaktivierten Interrupts reaktiviert. Dadurch kann die ISR von einer IRQ unterbrochen werden. Das bietet die Möglichkeit, so etwas wie Interrupt-Priorisierung nachzubilden, was AVRs selbst nicht können. Weiterhin kann man schneller auf bestimmte Ereignisse reagieren. Tritt während der ISR ein anderer IRQ auf, der schnell bedient werden muss, kann sofort der dringende ISR-Code ausgeführt werden. Ansonsten (Verwendung von <tt>SIGNAL</tt>) würde der Code erst ausgeführt werden, nachdem die aktuelle ISR beendet ist.

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

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

===Interrupts aktivieren===

Damit eine ISR überhaupt zur Ausführung kommt, müssen drei Bedingungen erfüllt sein
* Interrupts müssen global aktiviert sein
* Der entsprechen IRQ muss aktiviert worden sein
* Das zum IRQ gehörende Ereignis muss eintreten
<pre>
#include <avr/io.h>
#include <avr/interrupt.h>

...
// enable OutputCompareA Interrupt für Timer1
TIMSK |= (1 << OCIE1A);

// disable OutputCompareA Interrupt für Timer1
TIMSK &= ~(1 << OCIE1A);

// Interrupts aktivieren
sei();

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

===default Interrupt===

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

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

SIGNAL (__vector_default)
...
</pre>
Damit wird von <tt>__bad_interrupt</tt> aus nicht nach Adresse 0 gesprungen,
sondern weiter zu <tt>__vector_default</tt>, welches durch <tt>SIGNAL</tt> oder
<tt>INTERRUPT</tt> den üblichen ISR-Prolog/Epilog bekommt.

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

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

Wenn man in einer ISR komplett eigenes Zeug machen will,
dann definiert man eine nackte Funktion.
Mit <tt>naked</tt> befreit man die Routine vom Standard-Prolog/Epilog.
{{FarbigerRahmen|
Dabei ist darauf zu achten, daß die ISR mit <tt>reti</tt> (return from interrupt)
zurückkehrt und evtl. verwendete Register und den Status (<tt>SREG</tt>) sichert.
}}
<pre>
#include <avr/io.h>

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

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

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

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

while (*str++)
len++;

return len;
}
</pre>

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

===String im Flash belassen===
Oftmals werden Strings nur zu Ausgabezwecken verwendet und nicht verändert. Verwendet man Sequenzen der Gestalt
<pre>
char *str1 = "Hallo Welt!";
char str2[] = "Hallo Welt!";
</pre>
dann werden die Strings im SRAM abgelegt. Im Startup-Code werden die Strings vom Flash ins SRAM kopiert und belegen daher sowohl Platz im SRAM als auch im Flash. Wird ein String nicht verändert, braucht er nicht ins SRAM kopiert zu werden. Das spart Platz im knapp bemessenen SRAM. Allerdings muss anders auf den String zugegriffen werden, denn wegen der Harvard-Architektur des AVR-Kerns kann avr-gcc anhand der Adresse nicht unterscheiden, ob diese ins SRAM, ins Flash oder ins EEPROM zeigt.
<pre>
#include <avr/pgmspace.h>

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

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

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

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

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

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

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

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

==Reset auslösen==
Falls ein Reset per Software ausgelöst werden soll, dann geht das am besten über den [[Watchdog]].
Einfach nur an den RESET-Punkt an Adresse 0 zu springen mit
goto *((void**) 0);
initialisiert zwar den Controller von neuem, aber es macht keinen wirkliches RESET mit Zurücksetzen der Hardware und allen I/O-Registern.

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

#include <avr/wdt.h>
#include <avr/interrupt.h>
...
cli(); {{ccomment|Interrupts global abschalten}}
wdt_enable (WDTO_15MS); {{ccomment|Watchdog aufziehen auf 15ms}}
while (1); {{ccomment|warten, bis er zubeisst...}}

Welches Ereignis einen RESET ausgelöst hat, kann man im Register '''MCUCSR''' (''MCU Control and Status Register'') erfahren. Es gibt 4 mögliche RESET-Quellen:
* Power-On Reset
* External Reset
* Brown-Out Reset
* Watchdog Reset

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

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

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

{{ccomment|MCUCSR zurücksetzen }}
MCUCSR = 0;

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

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

{{ccomment|status auswerten }}
...
}

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

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

Nach einen Reset und vor Aufruf von <tt>main</tt> werden Initialisierungen ausgeführt wie
* Setzen des Stackpointers
* Vorbelegung globaler Datenobjekte: Daten ohne Initializer werden zu 0 initialisert ([[avr-gcc/Interna#Sections|Section]] <tt>.bss</tt>). Für Daten mit Initializer (Section <tt>.data</tt>) werden die Werte aus dem Flash ins SRAM kopiert.
* Initialisierung von Registern wie R1, in dem bei avr-gcc immer die Konstante 0 gehalten wird.

Im Linker-Script werden Sections von <tt>.init0</tt> bis <tt>.init9</tt> definiert, die nacheinander abgearbeitet werden. Erst danach wird <tt>main</tt> betreten. Um Code früh auszuführen, legt man die Funktion in eine dieser Sections:

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

{{comment|!!! never call this function !!!}}
void code_init3 (void)
{
{{comment|Code}}
}

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

Zu beachten ist dabei
* Eine so definierte Funktion darf keinesfalls aufgerufen werden!
* Zuweisungen wie <tt>i=0;</tt> ergeben vor <tt>.init3</tt> inkorrekten Code, da vor Ende von <tt>.init2</tt> Register R1 noch nicht mit 0 besetzt ist, avr-gcc aber davon ausgeht, daß es eben diesen Wert enthält.
* Lokale Variablen müssen in Registern liegen, denn vor Ende von <tt>.init2</tt> ist der Stackpointer noch nicht initialisiert. Zudem ist die Funktion <tt>naked</tt>, hat also insbesondere keinen Prolog, der den Framepointer (Y-Register) setzen könnte, falls er benötigt wird.
* Gegebenenfalls ist daher die Verwendung von [[Inline-Assembler in avr-gcc|inline-Assembler]] angezeigt oder die Implementierung in einem eigenen Assembler-Modul, das dazu gelinkt wird. Der erzeugte Code ist im List-File zu überprüfen.
* Werden mehrere Funktionen in die selbe init-Section gelegt, ist die Reihenfolge ihrer Ausführung nicht spezifiziert und i.a. nicht die gleiche wie in der Quelle.
Unbenutzte init-Sections haben die Nummern 0, 1, 3 und 5 bis 8. Die verbleibenden werden vom Startup-Code verwendet:
;<tt>.init2</tt>: Initialisieren von R1 mit 0 und setzen des Stackpointers
;<tt>.init4</tt>: Kopieren der Daten vom Flash ins SRAM (<tt>.data</tt>) und löschen von <tt>.bss</tt>
;<tt>.init6</tt>: C++ Konstruktoren
;<tt>.init9</tt>: Sprung zu <tt>main</tt>

Ein Programmbeispiel für Code in einer init-Section ist in "[[Speicherverbrauch bestimmen mit avr-gcc#Dynamischer RAM-Verbrauch|Speicherverbrauch bestimmen mit avr-gcc]]".

=Includes=

Die mit
#include <...>
angegebenen Includes werden von avr-gcc in den
mit der Option '<tt>-I</tt>' anegegenen Pfaden gesucht.
Dem Compiler bekannt sind die Pfade
<GCC_HOME>/avr/include Standard (stdio.h, ...)
<GCC_HOME>/avr/include/avr AVR-spezifisch (avr/io.h, ...)
<GCC_HOME>/lib/gcc/avr/<GCC_VERSION>/include Standard, compilerabh. (limits.h, ...)

Gibt man z.B. an
#include <stdio.h>
dann wird automatisch in diesem Verzeichnis nach <tt>stdio.h</tt> gesucht.
In den Verzeichnissen stehen Standard-Includes, die benötigt werden, wenn man libc-Funktionen
oder mathematische Funktionen etc. verwendet.
AVR-spezifische Dinge stehen im Unterverzeichnis <tt>avr</tt>, etwa:
#include <avr/io.h>
{{FarbigerRahmen|
Als Pfad-Separator wird immer ein '''<tt>/</tt>''' verwendet, auch auf Windows-Betriebssystemen! Also kein '''<tt>\</tt>''' !
}}

==Standard==

ctype.h Zeichen-Umwandlungs-Makros und ctype Makros
errno.h Symbolische Namen für Fehlercodes
inttypes.h Definiert [u]intN_t wenn man genau N [un]signed Bits
braucht, ISO C99.
math.h Mathematische Funktionen: sin, cos, log, gamma, bessel, ...
setjmp.h libc unterstützt setjmp() und longjmp(), um direkt in eine
andere (nicht-lokale) Funktion zu springen.
stdio.h Standard I/O-Funktionen (printf, ...).
stdlib.h Deklariert grundlegende ISO C-Makros und -Funktionen
sowie einige AVR-spezifische Erweiterungen
string.h Stringoperationen auf NULL-terminierten Strings. (strlen, ...)
stdarg.h Funktionen mit variabler Argumenanzahl
limits.h Min- und Max-Werte von Skalaren (UCHAR_MAX, LONG_MIN, ...)

==AVR-spezifisch==

Die AVR-spezifischen Includes finden sich wie gesagt im Unterverzeichnis <tt>avr</tt>.
Die meisten dort befindlichen Header wird man nie direkt durch Angabe im C-File erhalten,
sondern durch Angabe von
#include <avr/io.h>
Dadurch werden z.B. genau die I/O-Header eingebunden, die zum AVR-Modell passen, also
*<tt>avr/iom8.h</tt> für [[ATmega8]],
*<tt>avr/iotn2313.h</tt> für [[ATtiny2313]],
*<tt>avr/io2313.h</tt> für [[AT90S2313]], etc.

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

Obwohl diese Header nicht explizit angegeben werden müssen,
kann ein Blick dorthin hilfreich sein, um die Namen von [[SFR|SFRs]]
oder Signals nachzuschlagen.
Diese Header werden im folgenden nicht alle einzeln aufgelistet.
Ihre Namen sind immer <tt>avr/io*.h</tt>.
* für ATmega: <tt>avr/iom*.h</tt>
* für ATtiny: <tt>avr/iotn*.h</tt>
<pre>
avr/boot.h Bootloader Support
avr/crc16.h [*] Prüfsumme CRC16
avr/delay.h [*] Verzögerungsschleifen für kurze, exakte Verzögerungen
avr/eeprom.h EEPROM-Routinen
avr/ina90.h Kompatibilität mit IAR-AVR-Compiler
avr/interrupt.h sei(), cli(), ...
avr/io.h --> inttypes.h, io*.h
avr/io*.h SFRs, SIG_****, SPM_PAGESIZE, RAMEND, XRAMEND, E2END, FLASHEND
avr/parity.h [*] Parität
avr/pgmspace.h Zugriff aufs Flash: Byte lesen, PROGMEM, prog_char, prog_uint8_t, ...
avr/portpins.h Makros für Port-Pins
avr/signal.h [**] Makros SIGNAL() und INTERRUPT(), ...
avr/sleep.h Power-Safe
avr/twi.h [*] I2C
avr/wdt.h Watchdog

util/crc16.h Prüfsumme CRC16
util/delay.h Verzögerungsschleifen für kurze, exakte Verzögerungen
util/parity.h Parität
util/twi.h I2C

[*] bei neueren avr-gcc-Versionen in util
[**] entfällt bei neueren avr-gcc-Versionen. Stattdessen avr/interrupt.h verwenden
</pre>

==Anwendungs-spezifisch==
Eigene Header, die nur innerhalb eigener Projekte gebraucht werden, includet man mit
#include "..."
Auch hier darf man Unterverzeichnisse angeben oder ins übergeordnete Verzeichnis:
#include "../../mein-zeug.h"

=Optimierungen, Tipps & Tricks=

Beim Programmieren in C möchte man sich möglichst wenig mit der Codeerzeugung selbst auseinandersetzen. Man verwendet ja gerade deshalb einen Compiler und programmiert nicht in Assembler, weil man sich nicht um Register-Belegungen o.ä. kümmern will, sondern nur um die zu lösende Aufgabe.

GCC erzeugt zwar recht guten Code, aber er ist nicht perfekt. Gerade auf Systemen wie AVR mit nur sehr begrenzten Resourcen muss man daher dem Compiler hilfreich zur Seite stehen, wenn man noch dichteren/schnelleren Code erhalten möchte.

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

:''Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs."''

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

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

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

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

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

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

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

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

{{ccomment|"foo" wird im RAM angelegt. Ineffizient für konstante Strings!}}
{{ccomment|Beachte, daß damit strcmp (nicht strcmp_P) benutzt werden muss.}}
if (!strcmp (str_sram, "foo"))
{
{{ccomment|mach was bei Gleichheit}}
}

{{ccomment|PSTR bewirkt, daß die String-Konstante "foo"}}
{{ccomment|im Flash angelegt wird}}
if (!strcmp_P (str_sram, PSTR ("foo"))
{
{{ccomment|mach was bei Gleichheit}}
}
...
}

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

int func1 (int arg)
{
...
}

#define TEXT_LEN 15

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

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

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

{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}
const command_t * cmd = commands;

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

{{ccomment|Ja}}
int (*func)(int), arg;

{{ccomment|Dann Funktionszeiger und Argument besorgen,}}
func = (int(*)(int)) pgm_read_word (& cmd->func);
arg = (int) pgm_read_word (& cmd->arg);

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

{{ccomment|text ist nicht in commands}}
return -1;
}

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

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

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

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

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

{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}
const command_t * cmd = commands;

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

{{ccomment|Liest die Startadresse von str_x}}
text_P = (const prog_char *) pgm_read_word (& cmd->text);

{{ccomment|Ist das der gesuchte String?}}
if (strcmp_P (text, text_P))
{
...

==Lokale Variablen verwenden==

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

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

void foo2()
{
char var2 = var;

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

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

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

==Arithmetik==

=== Daten zerlegen/zusammensetzen ===

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

Oft benötigt wird der Zugriff auf die einzelnen Bytes eines <tt>int</tt>, also der Zugriff auf die Bytes eines 16-Bit-Wertes:

typedef union
{
unsigned char asByte[2];
unsigned short asWord;
int asInt;
} data16_t;

data16_t data;
...
int foo;
uint8_t wert;

data.asInt = foo;
wert = data.asByte[1]; {{ccomment|die oberen 8 Bits von foo}}

Ein komplexeres Beispiel, das noch mehr Datentypen überlagert:
typedef ... foo_t;

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

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

foo_t foo; {{ccomment| Zugriff als foo-Struktur }}
} data_t;

...
{
data_t data;

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

int anInt = data.foo.anInt; {{ccomment| liest ein Feld von foo (hier ein int) }}
...
}

===libgcc2 verwenden===

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

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

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

'''Beispiel: Umwandeln nach Dezimalstring'''

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

{{ccomment| Struktur definieren und Funktion bekannt machen }}
typedef struct
{
unsigned short quot;
unsigned short rem;
} udiv_t;

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

{{ccomment| 5 Ziffern (0...65535) und evtl. noch eine führende 0 }}
#define DIGITS 6

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

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

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

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

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

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

return s;
}

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

'''Beispiel: BCD-Umrechnung'''

Wandeln einer 8-Bit-Zahl <tt>0 <= num < 100</tt> nach [[BCD]]

typedef struct
{
unsigned char quot; {{ccomment| Quotient }}
unsigned char rem; {{ccomment| Rest (remainder) }}
} udiv8_t;

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

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

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

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

=Inkompatibilität=

[[GCC]] – und somit auch avr-gcc – werden ständig weiter entwickelt. Dies betrifft das Beheben von Fehlern, die Unterstützung neuer Architekturen/Sprachen/Betriebssysteme, Implementierung neuer Optimierungsalgorithmen, Vereinheitlichungen, etc.

Leider führt dies auch zu Inkompatibilitäten verschiedener avr-gcc-Versionen untereinander, und eine C-Quelle, die mit einer Version von avr-gcc fehler- und warnungsfrei übersetzt werden kann, ist mit einer anderen Version möglicherweise nicht compilierbar.

Die avr-gcc Version kann man anzeigen lassen, indem man in einer Shell/Eingabeaufforderung eintippt
avr-gcc -v

;<tt>#include <avr/signal.h></tt>: In Versionen bis 3.4.4 werden in dieser Header-Datei u.a. die Makros <tt>SIGNAL()</tt> und <tt>INTERRUPT()</tt> definiert, die man braucht, wenn man eine C-Funktion als Interrupt-Routine ([[ISR]]) kennzeichnen will. In neueren Versionen ab 3.4.5 sind diese Definitionen in den Header <tt>avr/interrupt.h</tt> gewandert, wo auch Makros wie <tt>sei()</tt> und <tt>cli()</tt> definiert werden. Die Inkludierung von <tt>avr/signal.h</tt> in den neueren avg-gcc Versionen führt zu einer Warnung, irgendwann vielleicht sogar zu einem Fehler, weil die Datei nicht mehr bei avr-gcc dabei ist und daher nicht mehr gefunden wird.
: '''Verwendet man bei einer älteren avr-gcc-Version <tt>SIGNAL</tt> bzw. <tt>INTERRUPT</tt> ohne <tt>avr/signal.h</tt> zu includen, wird u.U. stillschweigend falscher Code erzeugt.'''

;<tt>#include <util/...h></tt>: In <tt>util</tt> stehen jetzt Header wie <tt>util/parity.h</tt> oder das vielverwendete <tt>util/delay.h</tt>, die vormals im Include-Unterverzeichnis <tt>avr</tt> zu finden waren.

;Interrupt Service Routinen: Auch die API zur Definition von [[ISR]]s hat sich von avr-gcc Version 3.x zur Version 4.x geändert:
:'''avr-gcc 3.x'''
::{|
<pre>
SIGNAL (SIG_INTERRUPT0)
{
/* Interrupt Code */
}

INTERRUPT (SIG_OVERFLOW0)
{
/* Interrupt Code */
}
</pre>
|}

:'''avr-gcc 4.x'''
::{|
<pre>
ISR (INT0_vect)
{
/* Interrupt Code */
}

void TIMER0_OVF_vect (void) __attribute__((interrupt));
void TIMER0_OVF_vect (void)
{
/* Interrupt Code */
}
</pre>
|}

=Bugs=

;<tt>__builtin_return_address(0)</tt>: ist entgegen der Spezifikation nicht implementiert und liefert in der Regel ein falsches Ergebnis.

:'''Workaround''' (hier für eine ISR):
:{|
|-
|
#include <stdarg.h>
#include <avr/interrupt.h>

{{ccomment|The return address}}
unsigned short volatile return_addr;

{{ccomment|Define our special SIGNAL (INTERRUPT analoguous)}}
#define SIGNAL_BRA(signame,var) \
void signame (unsigned short var, ...) __attribute__ ((signal)); \
void signame (unsigned short var, ...)

#define SWAP_BYTES(x) (((x) >> 8) | ((x) << 8))

SIGNAL_BRA (SIG_OUTPUT_COMPARE1A, dummy)
{
{
va_list vlist;
va_start (vlist, dummy);

{{ccomment|Get the return address from the stack}}
dummy = va_arg (vlist, unsigned short);

{{ccomment|Convert stack address to code location}}
addr = SWAP_BYTES(dummy) << 1;
va_end (vlist);
}
{{ccomment|ISR Code}}
}
|}
;gcc 4.x: In der 4er-Version gab es tiefgreifende interne Änderungen im Compiler; er ist noch instabil und kann momentan nicht für den Produktiv-Einsatz empfohlen werden (Stand 02/2006).

:Die Auswirkungen der Optimierungen auf das Zielsystem <tt>avr</tt> bleibt abzuwarten, dürfte aber nicht wesentlich sein. Die neue 4-er Version wurde u.a. deshalb aufgelegt, um mit dem Intel-Compiler gleichzuziehen – also im Hinblick auf das Zielsystem <tt>i386</tt>) gemacht.

:Auch nach dem Release der 4-er Version wird die 3-er Version weiterentwickelt, da erst nach 1-2 Jahren nach Release einer neuer Major-Version ein Umstieg anzuraten ist und auch erst dann getätigt wird (zumindest im professionellen Bereich).

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

=Siehe auch=
* [[C-Tutorial]]
'''Code-Beispiele'''
* [[Hallo Welt für AVR (LED blinken)]] - ein erstes Beispiel für avr-gcc
*[[:Kategorie:Quellcode_C|C-Codebeispiele]]
* [[Fallstricke bei der C-Programmierung]]

'''Details'''
* [[Inline-Assembler in avr-gcc|Inline-Assembler]]
* [[avr-gcc/Interna|Interna von avr-gcc]]

'''Installation (Linux)'''
* [[avr-gcc und avrdude installieren]]
'''Sonstiges'''
* [[WinAVR]]
* [[Speicherverbrauch bestimmen mit avr-gcc]]
* [[Compiler]]
* [[Dev-Cpp IDE]]
* [[AVR]]
----
* [[Sourcevergleich]]
* [[Codevergleich AVR-Compiler]]

=Weblinks=
==Dokumentation==
* [http://gcc.gnu.org/onlinedocs/ GCC online documentation (en)] Offline findest du die Doku für gcc, cpp (Präprozessor) und avr-libc bei [[WinAVR]] in
:<pre><GCC_HOME>/doc/gcc/</pre>
: bzw.
:<pre><GCC_HOME>/doc/avr-libc/</pre>
:Online finden sich die Dokumente in
* [http://gcc.gnu.org/onlinedocs/gcc.pdf gcc.pdf (1900 kByte)] - Dokumentation des C/C++/Java-Compilers GCC (en)
* [http://gcc.gnu.org/onlinedocs/cpp.pdf cpp.pdf (470 kByte)] - Dokumentation des C-Präprozessors (en)
* [http://www.nongnu.org/avr-libc/user-manual/modules.html http://www.nongnu.org/avr-libc/user-manual] - Dokumentation zur avr-libc.

== Downloads==
* [http://sourceforge.net/projects/winavr/ WinAVR-Projekt bei sourceforge.net (en)]
* [http://cdk4avr.sourceforge.net/ avr-gcc und toolchain als Linux-Paket bei sourceforge.net (en)]
== Tipps, Installation ==
*[http://www.nongnu.org/avr-libc/user-manual/install_tools.html ''"Installing the GNU Tool Chain"''] Hilfe zum Build und Installation von GCC, binutils, etc unter Linux
* Im GCC-Handbuch, siehe [[#Dokumentation|Dokumentation]].
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml www.linuxfocus.org (Artikel)] - Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux
* [http://users.rcn.com/rneswold/avr/ Rich Neswold: ''A GNU Development Environment for the AVR Microcontroller'']
* [http://www.mikrocontroller.net/topic/24166 www.mikrocontroller.net (Foren-Beitrag)] - Installation von GCC und Toolchain unter Mac OS X
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=125603#125603 www.roboternetz.de (Foren-Beitrag)] ''avrgcc + avrdude installieren''

== Sonstiges ==
* [http://gcc.gnu.org/ Offizielle Homepage von GCC (en)]
* [http://de.wikipedia.org/wiki/GNU_Compiler_Collection GCC in der deutschen Wikipedia]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial avr-gcc-Tutorial auf mikrocontroller.net]
* [http://www.avrfreaks.net/AVRGCC/ avr-gcc bei avrfreaks.net (en)]
* [http://savannah.nongnu.org/projects/avr-libc/ Nützliche GCC Runtime-Libary]

=Autor=

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

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

Hallo Welt für AVR (LED blinken)

2006-11-28T21:05:19Z

Heigro: Typo

Das erste C-Programm, das man zu sehen bekommt, ist für die meisten das "Hallo Welt".
Bei "Hallo Welt" geht es weniger um die Funktionalität an sich, sondern darum zu lernen,
wie man überhaupt ein Programm übersetzt und einen Compiler verwendet.

Was für den PC das "Hallo Welt", ist für einen kleinen Microcontroller der "Hallo Blinky",
der einfach nur eine [[Diode|Leuchtdiode]] (LED) blinken lässt.

Im Vergleich zu "Hallo Welt" sieht der Blinky viel komplizierter aus,
aber eigentlich ist er einfacher, dann es werden keine umfangreichen Funktionen oder
Black-Boxen benutzt wie etwa <tt>printf()</tt>.
Ausser dem eingegebenen Quellcode kommt also kein anderer Code zur Ausführung!

{{FarbigerRahmen|
Bitte beachte auch die Hinweise zu [[avr-gcc#Inkompatibilität|Inkompatibilitäten von avr-gcc]]!
}}

=Beschreibung=

Eine [[LED]] an Port B1 wird einmal pro Sekunde an bzw. ausgeschaltet. Die LED blinkt also mit einer Frequenz von 1/2 Hz.

Im Programm wird der Wert für das OCR1A-Register aus der Taktfrequenz des
Controllers (<tt>F_CPU</tt>) und der Anzahl an Interrupts, die pro Sekunde
ausgelöst werden sollen (<tt>IRQS_PER_SECOND</tt>), berechnet.

Standardmässig sind [[AVR|AVRs]] mit dem internen RC-Oszillator mit ca. 1 MHz getaktet.
Daher wird <tt>F_CPU</tt> in <tt>blinky.c</tt> zu 1000000 definiert:
#define F_CPU 1000000
{{FarbigerRahmen|
Dieser Wert hat rein informativen Charakter und bewirkt ''nicht'', daß der Controller mit einer anderen Frequenz läuft! Das geht über einen anderen Quarz/Oszillator oder andere Fuse-Einstellungen.
}}

Das Programm ist ausgelegt für eine Taktrate von 1 MHz. Wenn dein [[Controller]] mit einem anderen Takt läuft, dann hast du zwei Möglichkeiten:
* Du lässt das Programm so, wie es ist. Dann blinkt die LED entsprechend schneller bzw. langsamer. Hast du deinen AVR zB mit 16 MHz getaktet, dann blinkt die LED mit 8 Hz.
* Du passt die Taktfrequenz in der Quelle oder per Kommandozeile an. Für 8 MHz:
:<pre> > avr-gcc ... -DF_CPU=8000000</pre>

=Quellcode=
Der Quellcode ist für die Version 3.x von [[avr-gcc]]. In der 4er-Version gab es tiefgreifende interne Änderungen im Compiler; er ist noch instabil und kann momentan noch nicht für den Produktiv-Einsatz empfohlen werden (Stand 02/2005).
#include <avr/io.h>
#include <avr/interrupt.h>

{{ccomment|Geblinkt wird PortB.1 (push-pull)}}
{{ccomment|Eine LED in Reihe mit einem Vorwiderstand zwischen}}
{{ccomment|PortB.1 und GND anschliessen.}}
#define PAD_LED 1
#define PORT_LED PORTB
#define DDR_LED DDRB

{{ccomment|Der MCU-Takt. Wird gebraucht, um Timer1 mit den richtigen}}
{{ccomment|Werten zu initialisieren. Voreinstellung ist 1MHz.}}
{{ccomment|(Werkseinstellung für AVRs mit internem Oszillator).}}
{{ccomment|Das Define wird nur gemacht, wenn F_CPU noch nicht definiert wurde.}}
{{ccomment|F_CPU kann man so auch per Kommandozeile definieren, z.B. für 8MHz:}}
{{ccomment|avr-gcc ... -DF_CPU=8000000}}
{{ccomment|  }}
{{ccomment|! Der Wert von F_CPU hat rein informativen Character für}}
{{ccomment|! die korrekte Codeerzeugung im Programm!}}
{{ccomment|! Um die Taktrate zu ändern müssen die Fuses des Controllers}}
{{ccomment|! und/oder Quarz/Resonator/RC-Glied/Oszillator}}
{{ccomment|! angepasst werden!}}
#ifndef F_CPU
#define F_CPU 1000000
#endif

{{ccomment|So viele IRQs werden jede Sekunde ausgelöst.}}
{{ccomment|Für optimale Genauigkeit muss}}
{{ccomment|IRQS_PER_SECOND ein Teiler von F_CPU sein}}
{{ccomment|und IRQS_PER_SECOND ein Vielfaches von 100.}}
{{ccomment|Ausserdem muss gelten F_CPU / IRQS_PER_SECOND <= 65536}}
#define IRQS_PER_SECOND 2000 {{comment|500 µs}}

{{ccomment|Anzahl IRQs pro 10 Millisekunden}}
#define IRQS_PER_10MS (IRQS_PER_SECOND / 100)

{{ccomment|Gültigkeitsprüfung.}}
{{ccomment|Bei ungeeigneten Werten gibt es einen Compilerfehler}}
#if (F_CPU/IRQS_PER_SECOND > 65536) || (IRQS_PER_10MS < 1) || (IRQS_PER_10MS > 255)
# error Diese Werte fuer F_CPU und IRQS_PER_SECOND
# error sind ausserhalb des gueltigen Bereichs!
#endif

{{ccomment|Compiler-Warnung falls die Genauigkeit nicht optimal ist.}}
{{ccomment|Wenn das nervt für deine Werte, einfach löschen :-)}}
#if (F_CPU % IRQS_PER_SECOND != 0) || (IRQS_PER_SECOND % 100 != 0)
# warning Das Programm arbeitet nicht mit optimaler Genauigkeit.
#endif

{{ccomment|Prototypen}}
void wait_10ms (const uint8_t);
void timer1_init();

{{ccomment|Zähler-Variable. Wird in der ISR erniedrigt und in wait_10ms benutzt.}}
static volatile uint8_t timer_10ms;

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Implementierungen der Funktionen}}
{{ccomment|//////////////////////////////////////////////////////////////////////}}

#if !defined (TCNT1H)
#error Dieser Controller hat keinen 16-Bit Timer1!
#endif {{ccomment|TCNT1H}}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Timer1 so initialisieren, daß er IRQS_PER_SECOND }}
{{ccomment|IRQs pro Sekunde erzeugt.}}
void timer1_init()
{
{{ccomment|Timer1: keine PWM}}
TCCR1A = 0;

{{ccomment|Timer1 ist Zähler: Clear Timer on Compare Match (CTC, Mode #4)}}
{{ccomment|Timer1 läuft mit vollem MCU-Takt: Prescale = 1}}
#if defined (CTC1) && !defined (WGM12)
TCCR1B = (1 << CTC1) | (1 << CS10);
#elif !defined (CTC1) && defined (WGM12)
TCCR1B = (1 << WGM12) | (1 << CS10);
#else
#error Keine Ahnung, wie Timer1 fuer diesen AVR zu initialisieren ist!
#endif

{{ccomment|OutputCompare für gewünschte Timer1 Frequenz}}
{{ccomment|TCNT1 zählt immer 0...OCR1A, 0...OCR1A, ... }}
{{ccomment|Beim überlauf OCR1A -> OCR1A+1 wird TCNT1=0 gesetzt und im nächsten}}
{{ccomment|MCU-Takt eine IRQ erzeugt.}}
OCR1A = (unsigned short) ((unsigned long) F_CPU / IRQS_PER_SECOND-1);

{{ccomment|OutputCompareA-Interrupt für Timer1 aktivieren}}
#if defined (TIMSK1)
TIMSK1 |= (1 << OCIE1A);
#elif defined (TIMSK)
TIMSK |= (1 << OCIE1A);
#else
#error Keine Ahnung, wie IRQs fuer diesen AVR zu initialisieren sind!
#endif
}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Wartet etwa t*10 ms. }}
{{ccomment|timer_10ms wird alle 10ms in der Timer1-ISR erniedrigt. }}
{{ccomment|Weil es bis zum nächsten IRQ nicht länger als 10ms dauert,}}
{{ccomment|wartet diese Funktion zwischen (t-1)*10 ms und t*10 ms.}}
void wait_10ms (const uint8_t t)
{
timer_10ms = t;
while (timer_10ms);
}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Die Interrupt Service Routine (ISR).}}
{{ccomment|In interrupt_num_10ms werden die IRQs gezählt.}}
{{ccomment|Sind IRQS_PER_10MS Interrups geschehen, }}
{{ccomment|dann sind 10 ms vergangen.}}
{{ccomment|timer_10ms wird alle 10 ms um 1 vermindert und bleibt bei 0 stehen.}}
SIGNAL (SIG_OUTPUT_COMPARE1A)
{
static uint8_t interrupt_num_10ms;

{{ccomment|interrupt_num_10ms erhöhen und mit Maximalwert vergleichen}}
if (++interrupt_num_10ms == IRQS_PER_10MS)
{
{{ccomment|10 Millisekunden sind vorbei}}
{{ccomment|interrupt_num_10ms zurücksetzen}}
interrupt_num_10ms = 0;

{{ccomment|Alle 10ms wird timer_10ms erniedrigt, falls es nicht schon 0 ist.}}
{{ccomment|Wird verwendet in wait_10ms}}
if (timer_10ms != 0)
timer_10ms--;
}
}

{{ccomment|//////////////////////////////////////////////////////////////////////}}
{{ccomment|Das Hauptprogramm: Startpunkt }}
int main()
{
{{ccomment|LED-Port auf OUT}}
DDR_LED |= (1 << PAD_LED);

{{ccomment|Timer1 initialisieren}}
timer1_init();

{{ccomment|Interrupts aktivieren}}
sei();

{{ccomment|Endlosschleife}}
{{ccomment|Die LED ist jeweils 1 Sekunde an und 1 Sekunde aus,}}
{{ccomment|blinkt also mit einer Frequenz von 0.5 Hz}}
while (1)
{
{{ccomment|LED an}}
PORT_LED |= (1 << PAD_LED);

{{ccomment|1 Sekunde warten}}
wait_10ms (100);

{{ccomment|LED aus}}
PORT_LED &= ~(1 << PAD_LED);

{{ccomment|1 Sekunde warten}}
wait_10ms (100);
}

{{ccomment|main braucht keine return-Anweisung, weil wir nie hier hin kommen}}
}

=Von der C-Quelle zum hex-File=

Das Übersetzen über Kommandozeilen-Eingaben erledigt und ''nicht''
über Werkzeuge wie [[make]],
das die Zusammenhänge eher verschleiert als erhellt,
und dessen inkorrekte Anwendung eine häufige Fehlerquelle ist.

Nach Speichern der Quelldatein in ein eigenes Verzeichnis enthält dieses die Datei
blinky.c

==Compilieren==

Zunächst wird die C-Dateie übersetzt.
Der Übersetzungsvorgang wird gesteuert durch Kommandozeilen-Parameter (siehe [[avr-gcc]]).
Die Option
;<tt>-c</tt>: legt fest, daß nur compiliert wird (und nicht gelinkt),
;<tt>-o name</tt>: gibt den Name der Ausgabedatei an. Ohne diese Option heisst die Ausgabedatei immer <tt>a.out</tt>
;<tt>-mmcu=atmega8</tt>: legt den Controllertyp fest, in dem Beispiel den [[ATmega8]]
;<tt>-g</tt>: erzeugt Debug-Infos und
;<tt>-Os</tt>: optimiert auf Codegröße.
;<tt>-DF_CPU=xxx</tt>: optional, falls der Controller nicht mit 1 MHz läuft. <tt>xxx</tt> ist die Taktfrequenz in Hertz.
> avr-gcc blinky.c -c -o blinky.o -Os -g -mmcu=atmega8
Danach ist eine neue Datei entstanden (*.o)
blinky.c blinky.o

==Linken==
Die erzeugte Objek-Datei wird nun zur Ausgabedatei (*.elf) gelinkt:
> avr-gcc blinky.o -o blinky.elf -mmcu=atmega8
erzeugt die ausführbare Datei (*.elf), die noch zusätzliche Informationen wie
Debug-Infos etc. beinhaltet mit dem Namen <tt>blinky.elf</tt>:
blinky.c blinky.elf blinky.o

==Umwandeln nach hex==

===Code und Daten===
Viele Progger wollen die zu ladende Datei im Intel-hex-Format (*.hex bzw. *.ihex).
Dazu gibt man an
> avr-objcopy -j .text -j .data -O ihex blinky.elf blinky.hex
Damit enthält die hex-Datei die Sections <tt>.text</tt> (Programm) und <tt>.data</tt> (Daten).
Das Verzeichnis beinhaltet jetzt
blinky.c blinky.elf blinky.hex blinky.o

===EEPROM===
Ein hex-File, das den Inhalt des EEPROMs wiederspiegelt, erhält man mit
> avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex blinky.elf blinky_eeprom.hex
Für das Beispiel ist das EEPROM-File <tt>blinky_eeprom.hex</tt> leer,
da wir keine Daten ins EEPROM gelegt haben.

==Listfile erstellen==

Falls man ein Listfile haben möchte, dann geht das mit
> avr-objdump -h -S -j .text -j .data blinky.elf > blinky.lst
Das Listfile ist eine Textdatei, die alle Assembler-Befehle auflistet,
wie sie letztendlich auf den Controller geladen werden.

<tt>avr-objdump</tt> gibt seine Ausgabe auf das Terminal aus.
Diese Ausgabe wird mit '<tt>></tt>' in die Datei <tt>blinky.lst</tt> umgeleitet.
Hier ein Ausschnitt aus dem Listfile:
<pre>
00000072 <wait_10ms>:

// //////////////////////////////////////////////////////////////////////
// Wartet etwa t*10 ms.
// timer_10ms wird alle 10ms in der Timer1-ISR erniedrigt.
// Weil es bis zum nächsten IRQ nicht länger als 10ms dauert,
// wartet diese Funktion zwischen (t-1)*10 ms und t*10 ms.
void wait_10ms (const uint8_t t)
{
timer_10ms = t;
72: 80 93 61 00 sts 0x0061, r24
while (timer_10ms);
76: 80 91 61 00 lds r24, 0x0061
7a: 88 23 and r24, r24
7c: e1 f7 brne .-8 ; 0x76 <wait_10ms+0x4>
7e: 08 95 ret
</pre>
Links stehen die Adressen, dann die Maschinencodes der Befehle,
danach die Maschinencodes in Assembler-Darstellung.
Ganz rechts nach dem Kommentarzeichen '<tt>;</tt>' stehen die Dezimalcodes von
Konstanten oder die Zieladressen von Sprüngen, wie bei dem <tt>brne</tt>-Befehl an Adresse 7c, der gegebenenfalls
8 Bytes zurückspringt und dann an Adresse 76 landet.

==Mapfile erstellen==
Ein Mapfile gibt Auskunft darüber, an welcher Adresse Code und Objekte
landen. Erstellt wird das Mapfile während des Linkens, indem <tt>avr-gcc</tt>
ein Option an den Linker weiterreicht, die diesem zum Erstellen eines solchen Files veranlasst:
> avr-gcc blinky.o -o blinky.elf ... -Wl,-Map,blinky.map
Dadurch entsteht das Mapfile <tt>blinky.map</tt>.

==Die Größe ermitteln==

Die Größe der erhaltenen Objekte/Files können mit <tt>avr-size</tt> ausgegeben werden.
> avr-size -x blinky.o
druckt aus:
text data bss dec hex filename
0x7c 0x0 0x2 126 7e blinky.o
Das sind die Größen der einzelnen [[avr-gcc/Interna#Sections|Sections]].
Für das Flash relevant ist die Größe von
<tt>.text</tt> (Code) + <tt>.data</tt> (initialisierte Daten),
für das SRAM relevent ist <tt>.data</tt> (initialisierte Daten)
+ <tt>.bss</tt> (null-initialisierte Daten).

Im Flash werden also 126+0=126 Bytes belegt, und im SRAM 0+2=2 Bytes.

Ab binutils 2.16 gibt es für <tt>avr-size</tt> die Option <tt>-C</tt>, mit der man eine Zusammenfassung des ganzen Programms ausgeben kann:
> avr-size -C --mcu=atmega8 blinky.elf
druckt aus:
<pre>
AVR Memory Usage
----------------
Device: atmega8

Program: 216 bytes (2.6% Full)
(.text + .data + .bootloader)

Data: 2 bytes (0.2% Full)
(.data + .bss + .noinit)
</pre>

Die Gesamtgrösse ergibt sich erst aus dem elf-File,
denn auch die Vektortabelle und der Startup-Code belegen Platz. Hier eine Auflistung der beteiligten Sections:
> avr-size -x -A blinky.elf
druckt aus:
<pre>
blinky.elf :
section size addr
.text 0xd8 0x0
.data 0x0 0x800060
.bss 0x2 0x800060
.noinit 0x0 0x800062
.eeprom 0x0 0x810000
.stab 0x36c 0x0
.stabstr 0x84 0x0
.debug_aranges 0x14 0x0
.debug_pubnames 0x48 0x0
.debug_info 0xfc 0x0
.debug_abbrev 0xa2 0x0
.debug_line 0x101 0x0
.debug_str 0xa6 0x0
Total 0x86b</pre>
Im Flash werden somit 0xd8+0=216 Bytes belegt, also 90 Bytes mehr als das Object benötigt; davon entfallen z.B. schon 38 Bytes auf die Vektortabelle des [[ATmega8]],
die 2*19 Bytes groß ist.

Die Größen einzelner Funktionen/Variablen lassen sich anzeigen mit
> avr-nm --size-sort -S blinky.elf
was nach Größe sortiert ausdruckt:
<pre>
00800060 00000001 b interrupt_num_10ms.0
00800061 00000001 b timer_10ms
00000072 0000000e T wait_10ms
0000005c 00000016 T timer1_init
000000bc 0000001c T main
00000080 0000003c T __vector_6
</pre>

= HEX-Dateien zu diesem C-Code =
Zu dieser C-Datei gibt es HEX-Dateien für einige AVRs. Siehe dazu [[HEX Beispiel-Dateien für AVR]].
=Spin-off=

Eine [[LED]] blinken zu lassen könnte auch wesentlich einfacher implementert werden,
also z.B. ohne Funktionsaufrufe oder [[Interrupt]]-Programmierung.

Neben der eigentlichen Aufgabe "LED blinken lassen" kann man an dem Code
aber noch andere Dinge lernen:
* Programmierung eines Interrupts
* Initialisierung von Timer1 als Zähler mit "Clear Timer on Compare Match"
* Bedingte Codeübersetzung/Controllerunterscheidung mit <tt>#ifdef</tt> (in <tt>timer1_init</tt>)
* Abchecken der Gültigkeit von Defines durch den Präprozessor

=Siehe auch=
* [[HEX Beispiel-Dateien für AVR]] - Aus diesem Quellcode erzeugte Binärdateien zum Download und Proggen.
* [[AVR]]
* [[avr-gcc]]
* [[Interrupt]]
* [[:Kategorie:Quellcode C|weitere C-Code Beispiele]]

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

Avr-gcc

2006-11-22T18:56:48Z

Heigro: Typo

'''avr-gcc''' ist ein freier C-[[Compiler]], mit dem man C-Programme zu ausführbaren Programmen übersetzen kann, die auf [[Microcontroller]]n der [[AVR]]-Familie lauffähig sind.
An Sprachen versteht avr-gcc sowohl C als auch [[#C%2b%2b|C++]].
Neben Standard-C bzw. ANSI-C versteht avr-gcc auch GNU-C, das etwas mehr Möglichkeiten und kleinere Spracherweiterungen bietet.

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

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

=How to Read=

Dieser Artikel bespricht avr-gcc Version 3.x. Er ist kein C-Tutorial und kein AVR-Handbuch – das würde den Umfang des Artikels bei weitem sprengen. Es gibt einen Unterartikel, der [[avr-gcc/Interna|Interna von avr-gcc]] zusammenfasst.

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

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

In den [[:Kategorie:Quellcode C|C-Codebeispielen]]
befindet sich das ausführlichere Beispiel "[[Hallo Welt für AVR (LED blinken)]]",
das nur eine [[Diode#Lumineszenzdiode|LED]] blinkt und zeigt,
wie ein kleines Projekt mit avr-gcc compiliert werden kann.

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

=Benutzer-Schnittstelle=

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

Im einfachsten Fall sieht ein Aufruf von avr-gcc also so aus:
> avr-gcc
Dabei das '<tt>></tt>' nicht mittippen, und ein ENTER am Ende der Zeile drücken.
Die Antwort bei korrekter Installation ist dann
avr-gcc: no input files
Was bedeutet: das Programm avr-gcc wurde vom Betriebssystem gefunden und konnte/durfte gestartet werden. Dann gibt avr-gcc eine Fehlermeldung aus und beendet die Ausführung, weil er keine Eingabedatei(en) bekommen hat was ja auch stimmt. Soweit ist also alles in Butter.

Um eine C-Datei <tt>foo.c</tt> mir avr-gcc optimiert zu einem lauffähigen elf-Programm <tt>foo.elf</tt> für einen [[ATmega32]] zu compileren, würde man angeben
> avr-gcc -O2 -mmcu=atmega32 foo.c -o foo.elf
Hat man seine Quellen auf zwei oder mehre Dateien verteilt, geht es analog:
> avr-gcc -O2 -mmcu=atmega32 foo.c foo2.c -o foo.elf

Will man nur eine Objekt-Datei erstellen (nur compilieren, nicht linken), dann geht das wie folgt. Das kann günstig sein bei grösseren Projekten, wenn man das Projekt neu erzeugen will, aber nur in einer Quelldatei was geändert hat. Oder wenn das Objekt in einer Bibliothek landen soll.
> avr-gcc -O2 -c -mmcu=atmega32 foo.c -o foo.o

Die ausführbare Gesamtdatei <tt>foo_all.elf</tt> erhält man dann, indem alle Objekte zusammenlinkt:
> avr-gcc -mmcu=atmega32 foo.o foo2.o foo3.o -o foo_all.elf

Um die ausführbare Datei in das oft verwendete Intex-HEX-Format umzuwandeln (einmal fürs Programm, einmal für ein Abbild des [[EEPROM]]s) gibt man an:
> avr-objcopy -O ihex -j .text -j .data foo_all.elf foo_all.hex
> avr-objcopy -O ihex -j .eeprom --change-section-lma .eeprom=0 foo_all.elf foo_all_eeprom.hex

----

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

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

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

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

==Maschinenspezifische Optionen für avr-gcc==
Maschinenabhängige Optionen beginnen immer mit '''-m'''
;-mmcu=xxx: Festlegen des Targets (Zielsystem/Controller), für das Code generiert werden soll. Je nach Target muss avr-gcc unterschiedliche Instruktionen verwendet und andere Startup-Dateien (<tt>crtxxx.o</tt>) einbinden. avr-gcc setzt spezielle Defines, um auch in der Quelle zwischen den Targets unterscheiden zu können, falls das notwendig sein sollte:
:{| border="0" cellpadding="0" cellspacing="0"
|
<pre>
#ifdef __AVR_AT90S2313__
/* Code fuer AT90S2313 */
#elif defined (__AVR_ATmega8__) || defined (__AVR_ATmega32__)
/* Code fuer Mega8 und Mega32 */
#else
#error Das ist noch nicht implementiert für diesen Controller!
#endif
</pre>
|}

Zwar gibt es für alle AVR-Derivate die <tt>avr/io.h</tt>, aber die AVR-Familien unterscheiden sich in ihrer Hardware; z.B. darin, wie I/O-Register heissen oder wie Hardware zu initialisieren ist. Diese Abhängigkeit kann man in unterschiedlichen Codestücken aufteilen und wie oben gezeigt bedingt übersetzen. Dadurch hat man Funktionalitäten wie <tt>uart_init</tt> auf unterschiedlichen Controllern und wahrt den Überblick, weil nicht für jede Controller-Familie eine extra Datei notwendig ist.
{|
|- valign="top"
|
:{| {{Blauetabelle}}
|+ '''AVR classic, <= 8 kByte'''
|- {{Hintergrund1}}
!|mcu || Builtin define
|-
|avr2 ||<tt>__AVR_ARCH__=2</tt>
|-
|[[AT90S2313|at90s2313]] ||<tt>__AVR_AT90S2313__</tt>
|-
|at90s2323 ||<tt>__AVR_AT90S2323__</tt>
|-
|at90s2333 ||<tt>__AVR_AT90S2333__</tt>
|-
|at90s2343 ||<tt>__AVR_AT90S2343__</tt>
|-
|attiny22 ||<tt>__AVR_ATtiny22__</tt>
|-
|attiny26 ||<tt>__AVR_ATtiny26__</tt>
|-
|at90s4414 ||<tt>__AVR_AT90S4414__</tt>
|-
|at90s4433 ||<tt>__AVR_AT90S4433__</tt>
|-
|at90s4434 ||<tt>__AVR_AT90S4434__</tt>
|-
|at90s8515 ||<tt>__AVR_AT90S8515__</tt>
|-
|at90c8534 ||<tt>__AVR_AT90C8534__</tt>
|-
|at90s8535 ||<tt>__AVR_AT90S8535__</tt>
|-
|at86rf401 ||<tt>__AVR_AT86RF401__</tt>
|}
| 
:{| {{Blauetabelle}}
|+ '''AVR classic, > 8 kByte'''
|- bgcolor="#ccccff"
! |mcu ||Builtin define
|-
|avr3 ||<tt>__AVR_ARCH__=3</tt>
|-
|atmega103 ||<tt>__AVR_ATmega103__</tt>
|-
|atmega603 ||<tt>__AVR_ATmega603__</tt>
|-
|at43usb320 ||<tt>__AVR_AT43USB320__</tt>
|-
|at43usb355 ||<tt>__AVR_AT43USB355__</tt>
|-
|at76c711 ||<tt>__AVR_AT76C711__</tt>
|}
|}

----

{|
|- valign="top"
|
:{| {{Blauetabelle}}
|+ '''AVR enhanced, <= 8 kByte'''
|- bgcolor="#ccccff"
!|mcu || Builtin define
|-
|avr4 ||<tt>__AVR_ARCH__=4</tt>
|-
|[[Atmel Controller Mega8|atmega8]] ||<tt>__AVR_ATmega8__</tt>
|-
|atmega8515 ||<tt>__AVR_ATmega8515__</tt>
|-
|atmega8535 ||<tt>__AVR_ATmega8535__</tt>
|}
|
:{| {{Blauetabelle}}
|+ '''AVR enhanced, > 8 kByte'''
|- bgcolor="#ccccff"
!|mcu ||Builtin define
|-
|avr5 ||<tt>__AVR_ARCH__=5</tt>
|-
|[[Atmel Controller Mega16 und Mega32|atmega16]] ||<tt>__AVR_ATmega16__</tt>
|-
|atmega161 ||<tt>__AVR_ATmega161__</tt>
|-
|atmega162 ||<tt>__AVR_ATmega162__</tt>
|-
|atmega163 ||<tt>__AVR_ATmega163__</tt>
|-
|atmega169 ||<tt>__AVR_ATmega169__</tt>
|-
|[[Atmel Controller Mega16 und Mega32|atmega32]] ||<tt>__AVR_ATmega32__</tt>
|-
|atmega323 ||<tt>__AVR_ATmega323__</tt>
|-
|[[ATMega64|atmega64]] ||<tt>__AVR_ATmega64__</tt>
|-
|[[Atmel Controller Mega128|atmega128]] ||<tt>__AVR_ATmega128__</tt>
|-
|at94k ||<tt>__AVR_AT94K__</tt>
|}
|}

----

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

----

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

=Dynamische Speicherallokierung=

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

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

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

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

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

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

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

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

{{comment|Mach was mit p[0] ... p[num_data-1]}}
...
}

=C++=

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

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

Weiterhin unterliegt der Einsatz von C++ je nach Compiler/Lib-Version bestimmten Einschränkungen:
*Einer kompletten C++ Implementierung fehlt die Unterstützung durch die <tt>libstdc++</tt>, dadurch fehlen Standardfunktionen, -Klassen und -Templates
* Die Operatoren <tt>new</tt> und <tt>delete</tt> sind nicht implementiert, ihre Verwendung führt zu unauflösbaren externen Referenzen (Linker-Fehler)
*Nicht alle Header sind C++-sicher und müssen in <tt>extern "C" {...}</tt> eingeschlossen werden.
*Exceptions werden nicht unterstützt und müssen via <tt>-fno-exceptions</tt> abgeschaltet werden, oder der Linker beschwert sich über eine unauflösbare externe Referenz zu <tt>__gxx_personality_sj0</tt>.

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

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

#if defined (__cplusplus)
extern "C" {
#endif {{comment|__cplusplus}}

SIGNAL (SIG_NAME)
{
{{comment|machwas}}
}

INTERRUPT (SIG_NAME)
{
{{comment|mach was}}
}

#if defined (__cplusplus)
}
#endif {{comment|__cplusplus}}
<tt>__cplusplus</tt> ist ein Standard [[avr-gcc/Interna#Builtin Defines|GCC-Builtin-Define]].

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

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

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

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

===Zugiff auf Bytes und Worte===
For den Zugriff auf die SFRs gibt es Defines über den Include
#include <avr/io.h>
Abhängig vom eingestellten Controller werden denn Defines eingebunden, über die auf SFRs wie auf normale Variablen zugegriffen werden kann. Die Namen der Defines sind i.d.R. die gleichen wie im AVR-Manual, also z.b. <tt>SREG</tt> für das Prozessorstatus-Register SREG:
#include <avr/io.h>

...
{{ccomment|SREG lesen}}
uint8_t sreg = SREG;
...
{{ccomment|SREG schreiben}}
SREG = sreg;

Für einen Überblick über die eingebundenen Defines und kann ein Blick in den Controller-spezifischen Header hilfreich sein. Dieser befindet sich in
:<tt> <GCC_HOME>/avr/include/avr/io****.h</tt>
z.B. <tt>iom32.h</tt> für einen [[ATmega32]].

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

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

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

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

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

Etwas anders sieht der Code aus, wenn die Bits einzeln gesetzt werden und das Register im bitadressierbaren Bereich liegt (SRAM <tt>0x20</tt> bis <tt>0x3f</tt> resp. I/O <tt>0x0</tt> bis <tt>0x1f</tt>):
<pre>
// Ports B_0 und B_1 als Ausgang
DDRB |= (1<<PB0);
DDRB |= (1<<PB1);
</pre>
erzeugt
<pre>
b8 9a sbi 0x17, 0
b9 9a sbi 0x17, 1
</pre>

Um Bits zu löschen, erzeugt man eine Maske, die an der betreffenden Stelle eine  0 hat:
<pre>
// Ports B_2 als Eingang
DDRB &= ~(1<<PB2);
</pre>

{{FarbigerRahmen|
Auch hier ist zu beachten, daß es Probleme geben kann, wenn nicht atomarer Code erzeugt wird, weil der AVR-Befehlssatz nicht mehr hergibt:
<pre>
// toggle PORT B_0: wechseln 0 <--> 1
PORTB ^= (1<<PB0);
</pre>
ergibt
<pre>
88 b3 in r24, 0x18
; Wenn hier ein Interrupt auftritt, in dessen ISR PORTB verändert wird,
; dann wird die Änderung durch die letzte Instruktion wieder überschrieben!
91 e0 ldi r25, 0x01
; dito
89 27 eor r24, r25
; dito
88 bb out 0x18, r24
</pre>
}} 

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

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

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

==Interrupts==

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

Bitte beachte auch die Hinweise zu den [[#Inkompatibilität|Inkompatibilität]]en von avr-gcc!
<pre>
#include <avr/io.h>
#include <avr/signal.h>

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

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

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

{{FarbigerRahmen|
Die Schreibweise des Signal-Names muss genau die sein wie im Header, das schliesst auch Leerzeichen ein! Nicht alle GCC-Versionen bringen Fehler/Warnung, wenn die Schreibweise nicht stimmt.
SIGNAL (SIG_OUTPUT_COMPARE1A ) // !!! Macht NICHT das, was man will (Blank am Ende)!!!
}}

;<tt>SIGNAL</tt>: Mit Ausführung einer ISR deaktiviert die AVR-Hardware die Interrupts, sodaß die ISR nicht durch andere Interrupt-Anforderungen unterbrochen wird. Beim Verlassen der ISR werden Interrupts wieder aktiviert. Tritt während der ISR ein IRQ auf, wird diese erst nach Beenden des ISR-Codes ausgeführt. Der Interrupt geht also nicht verloren. Zwischen zwei ISRs wird zusätzlich mindestens ein Befehl des normalen Programm-Codes abgearbeitet.
;<tt>INTERRUPT</tt>: Früh im ISR-Prolog werden mit <tt>sei</tt> die von der AVR-Hardware temporär deaktivierten Interrupts reaktiviert. Dadurch kann die ISR von einer IRQ unterbrochen werden. Das bietet die Möglichkeit, so etwas wie Interrupt-Priorisierung nachzubilden, was AVRs selbst nicht können. Weiterhin kann man schneller auf bestimmte Ereignisse reagieren. Tritt während der ISR ein anderer IRQ auf, der schnell bedient werden muss, kann sofort der dringende ISR-Code ausgeführt werden. Ansonsten (Verwendung von <tt>SIGNAL</tt>) würde der Code erst ausgeführt werden, nachdem die aktuelle ISR beendet ist.

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

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

===Interrupts aktivieren===

Damit eine ISR überhaupt zur Ausführung kommt, müssen drei Bedingungen erfüllt sein
* Interrupts müssen global aktiviert sein
* Der entsprechen IRQ muss aktiviert worden sein
* Das zum IRQ gehörende Ereignis muss eintreten
<pre>
#include <avr/io.h>
#include <avr/interrupt.h>

...
// enable OutputCompareA Interrupt für Timer1
TIMSK |= (1 << OCIE1A);

// disable OutputCompareA Interrupt für Timer1
TIMSK &= ~(1 << OCIE1A);

// Interrupts aktivieren
sei();

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

===default Interrupt===

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

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

SIGNAL (__vector_default)
...
</pre>
Damit wird von <tt>__bad_interrupt</tt> aus nicht nach Adresse 0 gesprungen,
sondern weiter zu <tt>__vector_default</tt>, welches durch <tt>SIGNAL</tt> oder
<tt>INTERRUPT</tt> den üblichen ISR-Prolog/Epilog bekommt.

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

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

Wenn man in einer ISR komplett eigenes Zeug machen will,
dann definiert man eine nackte Funktion.
Mit <tt>naked</tt> befreit man die Routine vom Standard-Prolog/Epilog.
{{FarbigerRahmen|
Dabei ist darauf zu achten, daß die ISR mit <tt>reti</tt> (return from interrupt)
zurückkehrt und evtl. verwendete Register und den Status (<tt>SREG</tt>) sichert.
}}
<pre>
#include <avr/io.h>

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

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

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

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

while (*str++)
len++;

return len;
}
</pre>

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

===String im Flash belassen===
Oftmals werden Strings nur zu Ausgabezwecken verwendet und nicht verändert. Verwendet man Sequenzen der Gestalt
<pre>
char *str1 = "Hallo Welt!";
char str2[] = "Hallo Welt!";
</pre>
dann werden die Strings im SRAM abgelegt. Im Startup-Code werden die Strings vom Flash ins SRAM kopiert und belegen daher sowohl Platz im SRAM als auch im Flash. Wird ein String nicht verändert, braucht er nicht ins SRAM kopiert zu werden. Das spart Platz im knapp bemessenen SRAM. Allerdings muss anders auf den String zugegriffen werden, denn wegen der Harvard-Architektur des AVR-Kerns kann avr-gcc anhand der Adresse nicht unterscheiden, ob diese ins SRAM, ins Flash oder ins EEPROM zeigt.
<pre>
#include <avr/pgmspace.h>

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

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

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

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

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

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

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

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

==Reset auslösen==
Falls ein Reset per Software ausgelöst werden soll, dann geht das am besten über den [[Watchdog]].
Einfach nur an den RESET-Punkt an Adresse 0 zu springen mit
goto *((void**) 0);
initialisiert zwar den Controller von neuem, aber es macht keinen wirkliches RESET mit Zurücksetzen der Hardware und allen I/O-Registern.

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

#include <avr/wdt.h>
#include <avr/interrupt.h>
...
cli(); {{ccomment|Interrupts global abschalten}}
wdt_enable (WDTO_15MS); {{ccomment|Watchdog aufziehen auf 15ms}}
while (1); {{ccomment|warten, bis er zubeisst...}}

Welches Ereignis einen RESET ausgelöst hat, kann man im Register '''MCUCSR''' (''MCU Control and Status Register'') erfahren. Es gibt 4 mögliche RESET-Quellen:
* Power-On Reset
* External Reset
* Brown-Out Reset
* Watchdog Reset

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

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

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

{{ccomment|MCUCSR zurücksetzen }}
MCUCSR = 0;

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

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

{{ccomment|status auswerten }}
...
}

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

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

Nach einen Reset und vor Aufruf von <tt>main</tt> werden Initialisierungen ausgeführt wie
* Setzen des Stackpointers
* Vorbelegung globaler Datenobjekte: Daten ohne Initializer werden zu 0 initialisert ([[avr-gcc/Interna#Sections|Section]] <tt>.bss</tt>). Für Daten mit Initializer (Section <tt>.data</tt>) werden die Werte aus dem Flash ins SRAM kopiert.
* Initialisierung von Registern wie R1, in dem bei avr-gcc immer die Konstante 0 gehalten wird.

Im Linker-Script werden Sections von <tt>.init0</tt> bis <tt>.init9</tt> definiert, die nacheinander abgearbeitet werden. Erst danach wird <tt>main</tt> betreten. Um Code früh auszuführen, legt man die Funktion in eine dieser Sections:

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

{{comment|!!! never call this function !!!}}
void code_init3 (void)
{
{{comment|Code}}
}

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

Zu beachten ist dabei
* Eine so definierte Funktion darf keinesfalls aufgerufen werden!
* Zuweisungen wie <tt>i=0;</tt> ergeben vor <tt>.init3</tt> inkorrekten Code, da vor Ende von <tt>.init2</tt> Register R1 noch nicht mit 0 besetzt ist, avr-gcc aber davon ausgeht, daß es eben diesen Wert enthält.
* Lokale Variablen müssen in Registern liegen, denn vor Ende von <tt>.init2</tt> ist der Stackpointer noch nicht initialisiert. Zudem ist die Funktion <tt>naked</tt>, hat also insbesondere keinen Prolog, der den Framepointer (Y-Register) setzen könnte, falls er benötigt wird.
* Gegebenenfalls ist daher die Verwendung von [[Inline-Assembler in avr-gcc|inline-Assembler]] angezeigt oder die Implementierung in einem eigenen Assembler-Modul, das dazu gelinkt wird. Der erzeugte Code ist im List-File zu überprüfen.
* Werden mehrere Funktionen in die selbe init-Section gelegt, ist die Reihenfolge ihrer Ausführung nicht spezifiziert und i.a. nicht die gleiche wie in der Quelle.
Unbenutzte init-Sections haben die Nummern 0, 1, 3 und 5 bis 8. Die verbleibenden werden vom Startup-Code verwendet:
;<tt>.init2</tt>: Initialisieren von R1 mit 0 und setzen des Stackpointers
;<tt>.init4</tt>: Kopieren der Daten vom Flash ins SRAM (<tt>.data</tt>) und löschen von <tt>.bss</tt>
;<tt>.init6</tt>: C++ Konstruktoren
;<tt>.init9</tt>: Sprung zu <tt>main</tt>

Ein Programmbeispiel für Code in einer init-Section ist in "[[Speicherverbrauch bestimmen mit avr-gcc#Dynamischer RAM-Verbrauch|Speicherverbrauch bestimmen mit avr-gcc]]".

=Includes=

Die mit
#include <...>
angegebenen Includes werden von avr-gcc in den
mit der Option '<tt>-I</tt>' anegegenen Pfaden gesucht.
Dem Compiler bekannt sind die Pfade
<GCC_HOME>/avr/include Standard (stdio.h, ...)
<GCC_HOME>/avr/include/avr AVR-spezifisch (avr/io.h, ...)
<GCC_HOME>/lib/gcc/avr/<GCC_VERSION>/include Standard, compilerabh. (limits.h, ...)

Gibt man z.B. an
#include <stdio.h>
dann wird automatisch in diesem Verzeichnis nach <tt>stdio.h</tt> gesucht.
In den Verzeichnissen stehen Standard-Includes, die benötigt werden, wenn man libc-Funktionen
oder mathematische Funktionen etc. verwendet.
AVR-spezifische Dinge stehen im Unterverzeichnis <tt>avr</tt>, etwa:
#include <avr/io.h>
{{FarbigerRahmen|
Als Pfad-Separator wird immer ein '''<tt>/</tt>''' verwendet, auch auf Windows-Betriebssystemen! Also kein '''<tt>\</tt>''' !
}}

==Standard==

ctype.h Zeichen-Umwandlungs-Makros und ctype Makros
errno.h Symbolische Namen für Fehlercodes
inttypes.h Definiert [u]intN_t wenn man genau N [un]signed Bits
braucht, ISO C99.
math.h Mathematische Funktionen: sin, cos, log, gamma, bessel, ...
setjmp.h libc unterstützt setjmp() und longjmp(), um direkt in eine
andere (nicht-lokale) Funktion zu springen.
stdio.h Standard I/O-Funktionen (printf, ...).
stdlib.h Deklariert grundlegende ISO C-Makros und -Funktionen
sowie einige AVR-spezifische Erweiterungen
string.h Stringoperationen auf NULL-terminierten Strings. (strlen, ...)
stdarg.h Funktionen mit variabler Argumenanzahl
limits.h Min- und Max-Werte von Skalaren (UCHAR_MAX, LONG_MIN, ...)

==AVR-spezifisch==

Die AVR-spezifischen Includes finden sich wie gesagt im Unterverzeichnis <tt>avr</tt>.
Die meisten dort befindlichen Header wird man nie direkt durch Angabe im C-File erhalten,
sondern durch Angabe von
#include <avr/io.h>
Dadurch werden z.B. genau die I/O-Header eingebunden, die zum AVR-Modell passen, also
*<tt>avr/iom8.h</tt> für [[ATmega8]],
*<tt>avr/iotn2313.h</tt> für [[ATtiny2313]],
*<tt>avr/io2313.h</tt> für [[AT90S2313]], etc.

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

Obwohl diese Header nicht explizit angegeben werden müssen,
kann ein Blick dorthin hilfreich sein, um die Namen von [[SFR|SFRs]]
oder Signals nachzuschlagen.
Diese Header werden im folgenden nicht alle einzeln aufgelistet.
Ihre Namen sind immer <tt>avr/io*.h</tt>.
* für ATmega: <tt>avr/iom*.h</tt>
* für ATtiny: <tt>avr/iotn*.h</tt>
<pre>
avr/boot.h Bootloader Support
avr/crc16.h [*] Prüfsumme CRC16
avr/delay.h [*] Verzögerungsschleifen für kurze, exakte Verzögerungen
avr/eeprom.h EEPROM-Routinen
avr/ina90.h Kompatibilität mit IAR-AVR-Compiler
avr/interrupt.h sei(), cli(), ...
avr/io.h --> inttypes.h, io*.h
avr/io*.h SFRs, SIG_****, SPM_PAGESIZE, RAMEND, XRAMEND, E2END, FLASHEND
avr/parity.h [*] Parität
avr/pgmspace.h Zugriff aufs Flash: Byte lesen, PROGMEM, prog_char, prog_uint8_t, ...
avr/portpins.h Makros für Port-Pins
avr/signal.h [**] Makros SIGNAL() und INTERRUPT(), ...
avr/sleep.h Power-Safe
avr/twi.h [*] I2C
avr/wdt.h Watchdog

util/crc16.h Prüfsumme CRC16
util/delay.h Verzögerungsschleifen für kurze, exakte Verzögerungen
util/parity.h Parität
util/twi.h I2C

[*] bei neueren avr-gcc-Versionen in util
[**] entfällt bei neueren avr-gcc-Versionen. Stattdessen avr/interrupt.h verwenden
</pre>

==Anwendungs-spezifisch==
Eigene Header, die nur innerhalb eigener Projekte gebraucht werden, includet man mit
#include "..."
Auch hier darf man Unterverzeichnisse angeben oder ins übergeordnete Verzeichnis:
#include "../../mein-zeug.h"

=Optimierungen, Tipps & Tricks=

Beim Programmieren in C möchte man sich möglichst wenig mit der Codeerzeugung selbst auseinandersetzen. Man verwendet ja gerade deshalb einen Compiler und programmiert nicht in Assembler, weil man sich nicht um Register-Belegungen o.ä. kümmern will, sondern nur um die zu lösende Aufgabe.

GCC erzeugt zwar recht guten Code, aber er ist nicht perfekt. Gerade auf Systemen wie AVR mit nur sehr begrenzten Resourcen muss man daher dem Compiler hilfreich zur Seite stehen, wenn man noch dichteren/schnelleren Code erhalten möchte.

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

:''Nevertheless it proves possible to debug optimized output. This makes it reasonable to use the optimizer for programs that might have bugs."''

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

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

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

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

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

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

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

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

{{ccomment|"foo" wird im RAM angelegt. Ineffizient für konstante Strings!}}
{{ccomment|Beachte, daß damit strcmp (nicht strcmp_P) benutzt werden muss.}}
if (!strcmp (str_sram, "foo"))
{
{{ccomment|mach was bei Gleichheit}}
}

{{ccomment|PSTR bewirkt, daß die String-Konstante "foo"}}
{{ccomment|im Flash angelegt wird}}
if (!strcmp_P (str_sram, PSTR ("foo"))
{
{{ccomment|mach was bei Gleichheit}}
}
...
}

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

int func1 (int arg)
{
...
}

#define TEXT_LEN 15

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

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

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

{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}
const command_t * cmd = commands;

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

{{ccomment|Ja}}
int (*func)(int), arg;

{{ccomment|Dann Funktionszeiger und Argument besorgen,}}
func = (int(*)(int)) pgm_read_word (& cmd->func);
arg = (int) pgm_read_word (& cmd->arg);

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

{{ccomment|text ist nicht in commands}}
return -1;
}

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

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

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

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

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

{{ccomment|Wandert durch das Array mit Kommando-Strukturen}}
const command_t * cmd = commands;

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

{{ccomment|Liest die Startadresse von str_x}}
text_P = (const prog_char *) pgm_read_word (& cmd->text);

{{ccomment|Ist das der gesuchte String?}}
if (strcmp_P (text, text_P))
{
...

==Lokale Variablen verwenden==

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

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

void foo2()
{
char var2 = var;

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

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

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

==Arithmetik==

=== Daten zerlegen/zusammensetzen ===

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

Oft benötigt wird der Zugriff auf die einzelnen Bytes eines <tt>int</tt>, also der Zugriff auf die Bytes eines 16-Bit-Wertes:

typedef union
{
unsigned char asByte[2];
unsigned short asWord;
int asInt;
} data16_t;

data16_t data;
...
int foo;
uint8_t wert;

data.asInt = foo;
wert = data.asByte[1]; {{ccomment|die oberen 8 Bits von foo}}

Ein komplexeres Beispiel, das noch mehr Datentypen überlagert:
typedef ... foo_t;

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

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

foo_t foo; {{ccomment| Zugriff als foo-Struktur }}
} data_t;

...
{
data_t data;

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

int anInt = data.foo.anInt; {{ccomment| liest ein Feld von foo (hier ein int) }}
...
}

===libgcc2 verwenden===

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

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

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

'''Beispiel: Umwandeln nach Dezimalstring'''

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

{{ccomment| Struktur definieren und Funktion bekannt machen }}
typedef struct
{
unsigned short quot;
unsigned short rem;
} udiv_t;

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

{{ccomment| 5 Ziffern (0...65535) und evtl. noch eine führende 0 }}
#define DIGITS 6

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

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

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

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

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

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

return s;
}

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

'''Beispiel: BCD-Umrechnung'''

Wandeln einer 8-Bit-Zahl <tt>0 <= num < 100</tt> nach [[BCD]]

typedef struct
{
unsigned char quot; {{ccomment| Quotient }}
unsigned char rem; {{ccomment| Rest (remainder) }}
} udiv8_t;

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

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

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

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

=Inkompatibilität=

[[GCC]] – und somit auch avr-gcc – werden ständig weiter entwickelt. Dies betrifft das Beheben von Fehlern, die Unterstützung neuer Architekturen/Sprachen/Betriebssysteme, Implementierung neuer Optimierungsalgorithmen, Vereinheitlichungen, etc.

Leider führt dies auch zu Inkompatibilitäten verschiedener avr-gcc-Versionen untereinander, und eine C-Quelle, die mit einer Version von avr-gcc fehler- und warnungsfrei übersetzt werden kann, ist mit einer anderen Version möglicherweise nicht compilierbar.

Die avr-gcc Version kann man anzeigen lassen, indem man in einer Shell/Eingabeaufforderung eintippt
avr-gcc -v

;<tt>#include <avr/signal.h></tt>: In Versionen bis 3.4.4 werden in dieser Header-Datei u.a. die Makros <tt>SIGNAL()</tt> und <tt>INTERRUPT()</tt> definiert, die man braucht, wenn man eine C-Funktion als Interrupt-Routine ([[ISR]]) kennzeichnen will. In neueren Versionen ab 3.4.5 sind diese Definitionen in den Header <tt>avr/interrupt.h</tt> gewandert, wo auch Makros wie <tt>sei()</tt> und <tt>cli()</tt> definiert werden. Die Inkludierung von <tt>avr/signal.h</tt> in den neueren avg-gcc Versionen führt zu einer Warnung, irgendwann vielleicht sogar zu einem Fehler, weil die Datei nicht mehr bei avr-gcc dabei ist und daher nicht mehr gefunden wird.
: '''Verwendet man bei einer älteren avr-gcc-Version <tt>SIGNAL</tt> bzw. <tt>INTERRUPT</tt> ohne <tt>avr/signal.h</tt> zu includen, wird u.U. stillschweigend falscher Code erzeugt.'''

;<tt>#include <util/...h></tt>: In <tt>util</tt> stehen jetzt Header wie <tt>util/parity.h</tt> oder das vielverwendete <tt>util/delay.h</tt>, die vormals im Include-Unterverzeichnis <tt>avr</tt> zu finden waren.

;Interrupt Service Routinen: Auch die API zur Definition von [[ISR]]s hat sich von avr-gcc Version 3.x zur Version 4.x geändert:
:'''avr-gcc 3.x'''
::{|
<pre>
SIGNAL (SIG_INTERRUPT0)
{
/* Interrupt Code */
}

INTERRUPT (SIG_OVERFLOW0)
{
/* Interrupt Code */
}
</pre>
|}

:'''avr-gcc 4.x'''
::{|
<pre>
ISR (INT0_vect)
{
/* Interrupt Code */
}

void TIMER0_OVF_vect (void) __attribute__((interrupt));
void TIMER0_OVF_vect (void)
{
/* Interrupt Code */
}
</pre>
|}

=Bugs=

;<tt>__builtin_return_address(0)</tt>: ist entgegen der Spezifikation nicht implementiert und liefert in der Regel ein falsches Ergebnis.

:'''Workaround''' (hier für eine ISR):
:{|
|-
|
#include <stdarg.h>
#include <avr/interrupt.h>

{{ccomment|The return address}}
unsigned short volatile return_addr;

{{ccomment|Define our special SIGNAL (INTERRUPT analoguous)}}
#define SIGNAL_BRA(signame,var) \
void signame (unsigned short var, ...) __attribute__ ((signal)); \
void signame (unsigned short var, ...)

#define SWAP_BYTES(x) (((x) >> 8) | ((x) << 8))

SIGNAL_BRA (SIG_OUTPUT_COMPARE1A, dummy)
{
{
va_list vlist;
va_start (vlist, dummy);

{{ccomment|Get the return address from the stack}}
dummy = va_arg (vlist, unsigned short);

{{ccomment|Convert stack address to code location}}
addr = SWAP_BYTES(dummy) << 1;
va_end (vlist);
}
{{ccomment|ISR Code}}
}
|}
;gcc 4.x: In der 4er-Version gab es tiefgreifende interne Änderungen im Compiler; er ist noch instabil und kann momentan nicht für den Produktiv-Einsatz empfohlen werden (Stand 02/2006).

:Die Auswirkungen der Optimierungen auf das Zielsystem <tt>avr</tt> bleibt abzuwarten, dürfte aber nicht wesentlich sein. Die neue 4-er Version wurde u.a. deshalb aufgelegt, um mit dem Intel-Compiler gleichzuziehen – also im Hinblick auf das Zielsystem <tt>i386</tt>) gemacht.

:Auch nach dem Release der 4-er Version wird die 3-er Version weiterentwickelt, da erst nach 1-2 Jahren nach Release einer neuer Major-Version ein Umstieg anzuraten ist und auch erst dann getätigt wird (zumindest im professionellen Bereich).

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

=Siehe auch=
* [[C-Tutorial]]
'''Code-Beispiele'''
* [[Hallo Welt für AVR (LED blinken)]] - ein erstes Beispiel für avr-gcc
*[[:Kategorie:Quellcode_C|C-Codebeispiele]]
* [[Fallstricke bei der C-Programmierung]]

'''Details'''
* [[Inline-Assembler in avr-gcc|Inline-Assembler]]
* [[avr-gcc/Interna|Interna von avr-gcc]]

'''Installation (Linux)'''
* [[avr-gcc und avrdude installieren]]
'''Sonstiges'''
* [[WinAVR]]
* [[Speicherverbrauch bestimmen mit avr-gcc]]
* [[Compiler]]
* [[Dev-Cpp IDE]]
* [[AVR]]
----
* [[Sourcevergleich]]
* [[Codevergleich AVR-Compiler]]

=Weblinks=
==Dokumentation==
* [http://gcc.gnu.org/onlinedocs/ GCC online documentation (en)] Offline findest du die Doku für gcc, cpp (Präprozessor) und avr-libc bei [[WinAVR]] in
:<pre><GCC_HOME>/doc/gcc/</pre>
: bzw.
:<pre><GCC_HOME>/doc/avr-libc/</pre>
:Online finden sich die Dokumente in
* [http://gcc.gnu.org/onlinedocs/gcc.pdf gcc.pdf (1900 kByte)] - Dokumentation des C/C++/Java-Compilers GCC (en)
* [http://gcc.gnu.org/onlinedocs/cpp.pdf cpp.pdf (470 kByte)] - Dokumentation des C-Präprozessors (en)
* [http://www.nongnu.org/avr-libc/user-manual/modules.html http://www.nongnu.org/avr-libc/user-manual] - Dokumentation zur avr-libc.

== Downloads==
* [http://sourceforge.net/projects/winavr/ WinAVR-Projekt bei sourceforge.net (en)]
* [http://cdk4avr.sourceforge.net/ avr-gcc und toolchain als Linux-Paket bei sourceforge.net (en)]
== Tipps, Installation ==
*[http://www.nongnu.org/avr-libc/user-manual/install_tools.html ''"Installing the GNU Tool Chain"''] Hilfe zum Build und Installation von GCC, binutils, etc unter Linux
* Im GCC-Handbuch, siehe [[#Dokumentation|Dokumentation]].
* [http://www.linuxfocus.org/Deutsch/November2004/article352.shtml www.linuxfocus.org (Artikel)] - Tipps zu Build und Installation von avr-gcc, binutils und avr-libc unter Linux
* [http://users.rcn.com/rneswold/avr/ Rich Neswold: ''A GNU Development Environment for the AVR Microcontroller'']
* [http://www.mikrocontroller.net/topic/24166 www.mikrocontroller.net (Foren-Beitrag)] - Installation von GCC und Toolchain unter Mac OS X
* [http://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=125603#125603 www.roboternetz.de (Foren-Beitrag)] ''avrgcc + avrdude installieren''

== Sonstiges ==
* [http://gcc.gnu.org/ Offizielle Homepage von GCC (en)]
* [http://de.wikipedia.org/wiki/GNU_Compiler_Collection GCC in der deutschen Wikipedia]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial avr-gcc-Tutorial auf mikrocontroller.net]
* [http://www.avrfreaks.net/AVRGCC/ avr-gcc bei avrfreaks.net (en)]
* [http://savannah.nongnu.org/projects/avr-libc/ Nützliche GCC Runtime-Libary]

=Autor=

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

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

AVR Assembler Einführung

2006-11-22T10:43:22Z

Heigro: Instruction Pointer (IP)

==AVR Assembler Einführung==
Es gibt mehrere Gründe, sich mit dem AVR-Assembler zu beschäftigen:
* reines Interesse
* Man hat eben keinen anderen Compiler, Bascom kostet ja was und GCC-C kann man möglicherweise genausowenig, also warum nicht gleich.
* Endlich Programmieren ohne Sprach-Restriktionen
* (theoretisch) sagenhaft schneller und kurzer Code

Dadurch ergeben sich aber auch verschiedene Haupt-Zielgruppen für eine Einführung. Die eine ist in einer oder mehreren anderen Sprachen durchaus versiert, und möchte endlich auch mal richtig in die Tiefen der Hardware steigen. Die andere ist totaler Neueinsteiger und hat gehört, daß man Micro-Controller am besten mit Assembler programmiert.

Es soll hier nur eine Starthilfe zum Einstieg gegeben werden. Viele Details und Varianten werden hier bei weitem nicht erschöpfend behandelt.

==Unterschiede zu anderen Sprachen==
Man kann Assembler nicht direkt mit anderen Hochsprachen vergleichen. Es ist falsch gesagt Assembler ist viel besser als C, oder C ist viel besser als Assembler.
Hochsprachen haben generell ihren Vorteil in kürzerer (Programmier-) Zeit viel mehr erreichen zu können. Wärend man in Assembler jedes Detail programmieren muss schreibt man in der Hochsprache was man genau möchte und der Compiler erledigt das dann für einen, indem er den Code dann in Assembler übersetzt.
Der Vorteil liegt also klar auf der Hand, man spart sich eine Menge (unnötiger) Arbeit in dem man schneller sagen kann was man eigentlich machen möchte. Wie das jetzt genau funktioniert und was man dabei beachten muss übernimmt der Compiler.
Da gibts dann aber auch schon den ersten Nachteil. Fängt man mit einer Hochsprache an, braucht man sich Hardwaremäßig kaum mit dem µC außeinander setzen und weiß deshalb auch nicht genau drüber bescheit. Funktioniert dann etwas nicht sitzt man auf dem Schlauch.
Die Compiler werden aber immer besser, so kommen immer seltener Fehler Zustande.

Ein weiterer Nachteil ist eine Glaubens Frage, da man sich kaum mehr mit der Hardware auseinander setzt und nicht wissen muss wie ein µC eigentlich funktioniert geht die "Kultur" verloren. Man lernt gar nicht zu schätzen was das Ding jetzt eigentlich leistet. Die Ansprüche werden immer höher gesetzt und jeder Aussetzer ist umso schlimmer.

Ein extremes Beispiel:
Ein eisener Geschäftsmann geht nach Spanien und braucht Arbeiter, er schickt einen Gehilfen auf die Suche nach Arbeiter und schickt diese dann aufs Feld arbeiten. Ohne auch nur irgend etwas über deren Kultur zu wissen verlangt er das hart gearbeitet wird.
Doch schon in der ersten Woche gibt es Probleme, die Arbeiter möchten Mittags eine Pause. "Was, eine 3 Stündige Siesta? Seit ihr verrückt? Die in Japan arbeiten die Mittagszeit ja auch durch! Wie kommt ihr auf die Idee 3 Stunden pause zu machen?"

Vorteile von Assembler sind also das man weiß was der µC genau macht (bzw. für Anfänger "was er tun sollte").
Man hat die volle Kontrolle und fast jeder Befehl wird bei einem AVR mit einem Takt ausgeführt.
Man kann immer noch auf eine andere Hochsprache umsteigen, diese beherscht man dann um so besser.

Einzigster Nachteil, man muss alles genau definieren, so wie es der µC haben möchte und kann nicht direkt auf fertige funktionen zurück greifen.
Man schaft in der selben Zeit zwar genau so viel Code, der Code macht dann aber weniger als in C.

Bildhaft ist der Unterschied der: Beim Assembler hat man ein weißes Stück Papier (ohne Linien) und ein Alphabet von A-Z. Aus diesen Buchstaben soll man nun erstmal Worte suchen und dann damit einen sinnvollen Text verfassen.

Bei "höheren" Sprachen ist das Papier zumindest mal liniert, und dazu kriegt man auch ein Wörtebuch und die Grammatik. Teile des Textes sind schon vorgeschrieben und ich muß nurmehr bei den ..... Punkten was einsetzen.

Anderst kann man auch sagen Hochsprachen sind wie ein Baukasten, man muss nur nach seinen Bedürfnissen sich die Teile zusammen "stecken", ab und zu fertig man sich auch eigene Teile. Aber das meiste ist vorgefertigt und nach eigenen Bedürfnissen schnell angepasst.
In Assembler muss man sich alles selber anfertigen, fertige Module gibt es nicht, es sei denn man hat es schon einmal gemacht und zufällig da.

* Daten
Höherer Sprachen kennen alle möglichen Datentypen in allen möglichen Längen, integer, floating point, Strings. Dadurch sind aber auch gleich die möglichen und zulässigen Operationen schon eingeschränkt.

Beim (AVR) Assembler gibt auch einige Datentypen. Sie unterscheiden sich aber nur durch die Größe, d.h. die Anzahl der Bytes, die sie belegen. Es gibt aber keine Einschränkungen bezüglich der Befehle, die man darauf anwenden kann.

* Vor- und Nachteile
Wenn man den Assembler mit höheren Sprachen vergleicht, um vielleicht Vor- und Nachteile herausarbeiten zu können, kommt man schnell drauf, daß in jedem Vorteil für eine der Seiten auch schon der Nachteil drinnen steckt. Was ich beim Assembler an Performance heraushole, weil ich z.B. "Goodies" eines Controllers ausnutze, bezahle ich, wenn ich mir einen anderen kaufe und dann das ganze Programm umbauen muß.

==Installation AVR-Studio==
Die Installation des ATMEL AVR Studios ist herzergreifend einfach.
* Man bekommt von Atmel das AStudio4b01.exe (oder was halt gerade aktuell ist) , das man einfach startet und schon ist es passiert.
* Wenn man nun das Käferchen doppelklickt und startet,
**erzeugt man am besten gleich mal ein neues Project.
**Man wählt den Pfad des Projects, und
**Wenn man seinen Brennadapter im Menü nicht findet, wählt man eben den Simulator und verwendet dann halt das PonyProg, oder was man halt hat.
**avrstudio erzeugt ein leeres Projekt und eine leere Assemblersource, die so heißt wie das Projekt. Das Gewurstel mit der Make-file nimmt uns AvrStudio ab.
==Struktur eines AVR-Maschinenprogrammes==
Bei höheren Sprachen wird diese Struktur vom Compiler/Linker erzeugt, beim Assembler muß man sich selbst darum kümmern.

[[Bild:Asm_Flow.jpg]]

Der Controller beginnt mit der Abarbeitung links oben bei der Programmspeicheradresse 0000. Wenn man Interrupts verwenden will, muß man gleich das nächste Bereich (ISR-Vectoren) überspringen (mit "JMP"). Wenn nicht, kann man sich diese Vektoren aber auch wegdenken.

Man landet so oder so bei den Befehlen, die der Initialisierung dienen (Setzen der Startbedingung). Das ist zumindest die Festlegung des Stack-Pointers, sonst kann man keine "CALLS" oder Interrupts durchführen.

Danach kommt man von oben in die Haupt-Programm-Schleife, die (üblicherweise) immer wieder ohne Ende durchlaufen wird.

Das "End" ist bei Microcontrollern daher auch kaum wirklich notwendig. Wenn es da ist, ist das eine ewige Wiederholung eines einzigen Befehls.

==Source-Code Muster==
Das folgende Codebeispiel ist eine reine Basis-Initialisierung ohne irgendeine erkennbare Funktion. Für den Einstieg ist es am besten, das einfach abzuschreiben, wie es ist, und dann an den bezeichnenten Stellen mit eigenen Befehlen nach und nach zu erweitern.

<pre>
.NOLIST ; List-Output unterdrücken
.INCLUDE <m8def.inc> ; das gibt es für jeden Controllertyp
.LIST ; List-Output wieder aufdrehen
.CSEG ; was nun folgt, gehört in den FLASH-Speicher

;------------------------------------------------------
; Start Adresse 0000
;------------------------------------------------------
RESET:
jmp INIT ; springen nach "INIT"

;------------------------------------------------------
; ISR VECTORS
;------------------------------------------------------
; ..... hier kommen dann die Sprungadressen für die Interrupts rein
; dazu kommen wir noch

.ORG INT_VECTORS_SIZE ; dadurch haben wir für die Vektoren Platz gelassen
INIT:
;------------------------------------------------------
; INITIALIZE
;------------------------------------------------------
ldi r24,high(RAMEND) ;Stack Pointer setzen
out SPH,r24 ; "RAMEND" ist in m8def.inc (s.o.) festgelegt
ldi r24,low(RAMEND) ;
out SPL,r24 ;

;------------------------------------------------------
; eigene Initialisierungen
;------------------------------------------------------
;....
;....
;....

;------------------------------------------------------
; HAUPTSCHLEIFE
;------------------------------------------------------
Hauptschleife:
;.... eigene befehle
;.... eigene befehle
;.... eigene befehle
rjmp Hauptschleife ; immer wiederholen

;------------------------------------------------------
; ENDE
;------------------------------------------------------
Ende:
rjmp Ende
</pre>
===Der Ablauf der Übersetzung===
Der Assembler ist ja selbst auch nur ein Programm und zu Beginn recht spartanisch ausgestattet: Er hat einen Daten-Buffer zur Verfügung, in den er den Maschinencode hineinschreiben soll, einen Pointer (Zeiger) dazu, damit er immer weiß, wo er grad ist, und eine allgemeine Tabelle, wo er Texte mit Zahlen verknüpfen kann. Alles ist zu Beginn leer bzw. auf NULL.
Mit diesen Voraussetzungen fängt er an, unseren Source-Text zeilenweise zu lesen. Und in jeder Zeile (die nicht leer ist) erwartet er eine Anweisung, was zu tun ist
====Assembler Direktiven/Präprozessor====
Das sind Anweisungen an den Assembler selbst und erzeugen keine Maschinenbefehle. Im obigen Source-Beispiel sind einige enthalten.
.NOLIST
Normalerweise schreibt der Assembler ja eine Übersetzungsliste. Nach dieser Anweisung läßt er das bleiben
.INCLUDE <m8def.inc> ; das gibt es für jeden Controllertyp
sagt ihm, er soll jetzt erstmal die (text) datei "m8def.inc" lesen und genauso behandeln, als wäre diese Datei mit dem Editor hier reinkopiert worden.
.LIST
Ab nun wird wieder alles in der Übersetzungsliste protokolliert.
.CSEG
was danach folgt, bezieht sich auf den FLASH-Programm-Speicher

Gleich ein Hinweis: Der "AVR Assembler 2" geht dazu über, die C-Syntax für
Präprozessoranweisungen zu verwenden. Diese haben dann als Kennzeichen ein "#" vorangestellt.

====Bemerkungen / Kommentare====
;------------------------------------------------------
Alles, was NACH einem Strichpunkt steht, schreibt er einfach nur in die Übersetzungsliste, sonst macht er nix.
====Label (Sprungmarke)====
RESET:
Was gleich ganz links in der Zeile beginnt (und mit einem Doppelpunkt abgeschlossen ist) schreibt er einfach in die genannte Tabelle und den momentanen Wert des Instruction Pointers (IP) dazu. Sonst hat das im Moment keine weitere Bedeutung. Natürlich, wenn er den gleichen Text schon mal hatte, gibt es eine Fehlermeldung, denn '''ein Label muss eindeutig sein'''

====Commands====
jmp INIT ; springen nach "INIT"
Alles, was nicht ganz links steht und auch nix anderes ist, betrachtet der Assembler als "Command". Normalerweise ist das eben eine AVR-Instruktion aus dem "Instruction Set". Hier ist das "JMP", also im Programm einfach woanders weitermachen. Gut, aber wo ? Der Rechner braucht nun unbedingt eine Zahl, denn "INIT" sagt ihm ja nichts. Also sieht er nun in der Tabelle nach, ob er den Text "INIT" schon mal hatte. Hatte er nicht, den zu der Stelle weiter hinten, wo "INIT:" als Sprungmarke steht (s.o) ist er ja noch garnicht gekommen.

Ich kann leider nicht genau sagen, welche Strategie der AVR-Assembler nun anwendet, dazu gibt es keine Doku. Manche Assembler lesen erstmal überhaupt nur den Sourcetext von vorn bis hinten durch, um alle "Sprungmarken" zu sammeln (Pass I) und fangen dann nochmal von vorne an (Pass II), diesmal mit schon gefüllter Tabelle. Andere machen das etwas gefinkelter. Ist uns aber eigentlich egal.

Jedenfalls findet er letztlich den Text "INIT" und daneben steht die Nummer der Speicherstelle, wo wir eben "INIT:" hingeschrieben haben. Und nun schreibt der Assembler also den Maschinencode für "JMP" in den Buffer und dazu die Zahl aus der Tabelle. Das war mal ein Befehl, also addiert er auf seinen Zeiger eins drauf und ist mit diesem Befehl fertig.

====ORG / JMP====
Das, was für den Controller beim Ablauf dann ein "JMP" ist, ist das ".ORG" für den Compiler. Wenn also bislang der Assembler den FLASH-Speicher von 0 - nn mit Befehlen befüllt hat, macht er durch
.ORG INT_VECTORS_SIZE
mit der Stelle weiter, die er über die gleiche Tabelle unter "INT_VECTORS_SIZE" gefunden hat. Dieser Tabelleneintrag, genauso wie "RAMEND" an anderer Stelle, entsteht aus der Datei "m8def.inc". Wie im vorliegenen Fall macht man diese "Assembler-Jumps", um Speicherstellen freizuhalten.

==Merkwürdiges==
===Befehlsadressen / Byteadressen ===
[[Atmel Controller Mega16 und Mega32#Maschinen-Code|Ein Maschinenbefehl besteht aus maximal drei, bit-mäßig verschachtelten Teilen]]. Die meisten Befehle brauchen dafür genau 16 Bit (also zwei Byte), manchmal reicht das nicht, da gehören dann nochmal 16 Bit dazu. Kleiner als 16 Bit ist aber keiner. Aus diesem Grund wäre es natürlich sinnlos, Adressen für Befehle in Bytes auszudrücken, wenn es eh immer Vielfache von 2 sein müssen, das kleinste Bit einer solchen Adresse wäre ja immer null.

Also adressiert man Commands in "Worten" von 16 - Bit bzw. 2 Bytes

Beim Ablegen eines Labels (Sprungmarke) werden also Wortadressen in der Tabelle angelegt. Solange der Wert auch als Befehls-Adresse verwendet wird (z.B. "JMP ''Label''"), braucht das nicht zu kümmern, denn genauso will es der AVR ja dann auch haben. '''Wenn dort aber Daten stehen''' und wir wollen diese adressieren, müssen wird '''den Wert mal 2 nehmen''' (oder einmal nach links schieben, was dasselbe ist), sonst landen wir im Nirwana.
===3 ist nicht gleich 3 ===
Eine Zahl bedeutet also bei der Maschinensprache unter Umständen ganz was anderes, je nachdem, in welchem Zusammenhang sie verwendet wird. Bei allen Befehlen, die nur für die Register 16 - 31 gehen, steht im Maschinencode für das Register 16 nicht 16 drin, sondern 0. die "16" addiert er dann bei der Befehlsausführung drauf (für den Techniker: er braucht ja nur das Bit 24 hochzuziehen)
===GPR ist nicht gleich GPR===
Was auch beim Einstieg leicht irritieren kann ist der Umstand, daß die 32 sogenannten "'''G'''eneral '''P'''urpose '''R'''egister" irgendwie so gar nicht generell und gleich sind. Manche Befehle kann ich mit allen 32 Registern machen, einige nur mit R16-R31, andere von R24 aufwärts und dann sind da noch R26 bis R31, die heissen dann manchmal auch noch X, Y und Z
===SFR ist gar nicht gleich GPR===
'''S'''pecial '''F'''unction '''R'''egister sind überhaupt seltsam, die meisten GPR-Befehle gehen da gleich garnicht, dafür gibt es andererseits ein paar Bit-Manipulationen, die gehen wiederum nur mit diesen. Dann gibt es auch Bit-Abfragen, die gehen da wie dort und bewirken auch das Gleiche, aber dafür heissen sie dann anders.
===Assembler-Befehle===
Viele dieser Probleme nimmt uns der Assembler ab, viele aber nicht. Dort erscheinen die Instruktionen immer so
{| {{Blauetabelle}}
| ''' '''
| '''CMD'''
| '''ARG1'''
| '''ARG2'''
|}
wobei die Argumente 1 u. 2 optionell, d.h. bei Bedarf erscheinen. Command ist natürlich immer da.
Trotz der Hilfe des Assemblers durch "Warnings" und "Errors" ist bei den Argumenten aber immer Vorsicht geboten. Wir haben gehört, daß Arg 1 und Arg 2 im Grunde einfach nur zwei Zahlen sind, die dann zusammen mit dem Command-Code zum Maschinenbefehl werden. Wenn es dem Assembler also auch nur irgendwie gelingt, aus dem, was wir da hinschreiben, Zahlen zu machen die er umwandeln kann, nimmt er sie auch.

===Zwischenbilianz===
Einiges dieser sonderbaren Dinge lassen sich leicht erklären, manche schwer, manche mangels Unterlagen darüber garnicht. Deswegen versuch ich es hier auch gleich garnicht.

So oder so sind es Fakten, an die man sich am besten einfach gewöhnt. Das scheint und ist am Anfang sicher schwer, solange man noch mit den Befehlen einzeln kämpft. RISC-Befehle werden aber erst in bestimmten Gruppierungen überhaupt wirklich sinnvoll, und durch diese sich immer wieder wiederholenden Gruppen wird es sehr schnell leichter.

Beim Briefe schreiben denkt man ja auch nicht in Buchstaben, das wäre mühsam, sondern in Worten oder in ganzen Sätzen.

==Load & Store==
Die meisten Befehle für den AVR laufen nach dem Load & Store (Laden und Speichern) Prinzip ab. Das heißt, die Daten werden zuerst aus dem SRAM-Speicher (oder den I/O bzw. SFR Registern) in die allgemeinen Register (GPR) geladen, dort verarbeitet, und danach wieder in den SRAM oder die SFR zurückgestellt.

[[Bild:Asm_cmd.jpg]]

Das ist natürlich eine recht allgemeine Darstellung, aber es hilft, das Instruction Set des AVR schon ein wenig besser zu verstehen.

Es bedeutet, um z.B. ein Byte aus der einen Ecke des SRAM in eine andere zu kopieren, brauchen wir wenigstens 2 Maschineninstruktionen, einmal Load und einmal Store. Und wenn wir was an dem Byte ändern wollen, kommt diese Befehle natürlich dazu.

Es gibt zu (fast) jeder Art "Load"-Befehl ein Äquivalent als "Store", und zum Finden genügt es meist, statt "L" an der selben Stelle ein "S" zu nehmen.
<pre>
LDS GPR, adresse ; lade das Byte von der Adresse in ein GPR
STS adresse, GPR ; speichere den Inhalt von GPR in der Adresse
</pre>
Wenn es um die I/O Register (SFR) geht:
<pre>
IN GPR, I/O-Register ; GPR <-----I/O Register
OUT I/O-Register, GPR ; I/O Register <---- GPR
</pre>
Für feste Werte (Literals) gibt es natürlich keine Store-Variante, denn diese Werte stehen ja im FLASH (Programm) Speicher, und da kann man nicht einfach einzelne Bytes verändern.
<pre>
LDI GPR, wert
</pre>

===Beispiel===

An PORTC haben wir (mit Vorwiderständen) ein paar LED angeschlossen. Und die sollen einfach nur zeigen, welche 0-er und 1-er am PORTB anliegen.
<pre>
; Eigene Initialisierungen
LDI R24, 0 ; der wert "0" ins allgemeine Register R24
OUT DDRB, R24 ; das kommt ins Controll-register f. PortB
; dadurch sind diese PINs als INPUT festgelegt
LDI R24, 255 ; der wert "255" = FF ins allgemeine Register R24
OUT DDRC, R24 ; das kommt ins Controll-register f. PortC
; dadurch ist das Port auf OUTPUT gestellt
</pre>

<pre>
; Eigene Befehle (in der Hauptschleife)
IN R24, PINB ; die Bits vom PortB ins allgemeine Register R24
OUT PORTC, r24 ; schreiben wir nach PortC
; wo ein 1-er ist, leuchtet nun die LED
</pre>

Wenn wir diese Befehle in das Programm-Schema oben einfügen, haben wir also das erste Assemblerprogramm schon geschrieben.
====Programm-Map====
Eine interessanter Output, wenn wir dieses Programm mit F7 übersetzen lassen, ist die Map-File. Sie ist ein Abbild der oben genannten "Text <--> Adresse"-Tabelle

(gekürzt)
<pre>
AVRASM ver. 2.0.28 D:\avr_c\avrstudio\Dokutest\Dokutest.asm Sat Dec 10 11:23:45 2005
....
EQU sram_start 00000060
EQU sram_size 00000800
EQU ramend 0000085f
......
EQU sph 0000003e
EQU spl 0000003d
EQU portb 00000018
EQU ddrb 00000017
EQU pinb 00000016
EQU portc 00000015
EQU ddrc 00000014
EQU pinc 00000013
EQU int_vectors_size 0000002a
CSEG reset 00000000
CSEG init 0000002a
CSEG hauptschleife 00000032
CSEG ende 00000035
</pre>
Wir finden darin alle Sprungadressen und alle sonstigen Werte, die wir verwendet haben. Tatsächlich in den Maschinencode eingesetzt werden vom Assembler immer die Zahlen, die daneben stehen

===Pointer-Register===
In vielen Fällen ist es nicht sinnvoll, für Load & Store explizit jedesmal die Speicheradresse dazuschreiben zu müssen. Es können auch die Pointer Register X, Y und Z verwendet werden. Das sind die Register
R26:R27 = X
R28:R29 = Y
R30:R31 = Z
Da wir ja oft mehr Speicher haben als 256 Byte, werden immer zwei Register zusammengefaßt und können dadurch die Bereiche 0 - 65535 abdecken (64k). Gut, aber wie kriegen wir so große Zahlen da rein ? Wir haben ja nur einen 8-Bit Processor und nicht 16.

Wir müssen also die Adresse 8-Bit-weise übergeben, aber der Assembler hilft uns ja dabei.
<pre>
LDI R26, LOW(Adresse) ; R28 für "Y" u. R30 für "Z"
LDI R27, HIGH(Adresse) ; R29 für "Y" u. R31 für "Z"
</pre>
Mit diesem "LOW" und "HIGH" teilt uns der Assembler die Adresse genau in die richtigen 8-Bit Portionen, die wir also so in den "X" Pointer laden können.

Noch eine Hilfe gibt es: Wir können, besser zu merken, auch schreiben:
<pre>
LDI XL, LOW(Adresse) ; YL für "Y" u. ZL für "Z"
LDI XH, HIGH(Adresse) ; YH für "Y" u. ZH für "Z"
</pre>
Also "LOW" für "L" und "HIGH" für "H"

====Indirekte Adressierung====
Mit den Pointer-Register kann man also Indirekte Adressieren(=einmal um die Ecke). Statt:
<pre>
LDS GPR, adresse ; lade das Byte von der Adresse in ein GPR
</pre>
Schreiben wir
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
LD GPR, X ; '''Indirekt''': lade das Byte, wo der Pointer X hinzeigt
</pre>
beziehungsweise
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
ST X, GPR ; '''Indirekt''': speichern, wo der Pointer X hinzeigt
</pre>
Warum sollte man sowas kompliziertes tun ? Nun, zum Beispiel dann,
* wenn man an einer Stelle im Programm die Adresse festlegt, aber ganz woanders braucht (Subroutinen)
* wenn man für mehrere Folge-Befehle die gleiche Adresse wieder braucht
* wenn man mit der Adresse (als Zahl) rechnen will

====Post-Increment/Pre-Decrement====
Wenn ich zum Beispiel 4 Byte hintereinander im Speicher auf "0" löschen will
<pre>
LDI XL, LOW(Adresse)
LDI XH, HIGH(Adresse)
LDI GPR, 0
ST X+, GPR ;speichern, wo X hinzeigt, und dann 1 auf X addieren
ST X+, GPR ;das 2.Byte dahinter
ST X+, GPR ;das 3.Byte dahinter
ST X+, GPR ;das 4.Byte dahinter
</pre>
Durch das automatische Addieren brauche ich nichts weiter zu tun. Als Gegenstück dazu kann man auch jedesmal 1 abziehen lassen, das aber immer '''vorher'''
<pre>
ST -X, GPR ;1 von X abziehen und dann speichern, wo X hinzeigt
</pre>

All das gibt's für X, Y und Z. Es geht aber immer nur
* Load & Store und '''dann''' addieren
* '''erst''' subtrahieren und '''dann''' Load & Store
Diese Kombinationen werden einfach am häufigsten gebraucht

====Displacement====
Für die beiden Pointer Y und Z kann man auch mit Displacement arbeiten
<pre>
LDD GPR, Y+4 ; wo Y hinzeigt, aber 4 Byte dahinter
</pre>

==Welches Register ?==
Bei den Load & Store Befehlen könnten als GPR alle 32 Allgemeinen Register beliebig verwendet werden, um das entsprechende Byte aufzunehmen oder abzugeben. Aber als Zwischenspeicher oder Arbeitsregister ist es am besten, Registern wie r26->r31, die möglicherweise als Pointer gebraucht werden, eher auszuweichen.

Wird das Assemblerprogramm durch inline oder libraries in eine Hochsprache
eingebunden, muß man bei sich natürlich an die Register-Konventionen dieser
Umgebung halten.

Schreibt man ein "stand-alone" Programm, kann (und sollte) man sich seinen eigenen
Konventionen und Regeln schaffen. Das ist das, was der Assembler-Fan so liebt.

==Benutzerdaten==
Daten wie Variable oder Felder werden üblicherweise im SRAM abgelegt und (s.o) von dort auch geholt. Bei allen Compilern und natürlich auch beim Assembler können zum Programmierzeitpunkt nur die Adressen davon festgelegt werden, aber keine Inhalte. Erst zur Laufzeit des Programmes kommen hier Werte rein. Manche Compiler gaukeln es zwar vor, aber (ein C-Beispiel):
<pre>
char MeinName[] = "Sepp Meier"
</pre>
bewirkt in Wirklichkeit drei Dinge: Im SRAM wird die nächste, noch nicht benutzte Adresse dem Text "MeinName" in der oben genannten Tabelle abgelegt, der String "Sepp Meier" wird im FLASH Programmspeicher bereitgestellt, und es wird eine Transfer-Routine generiert, die beim tatsächlichen Start des fertigen Programmes diesen String in das Feld "MeinName" transferiert.

Im Assembler ist es eben genauso: Wir können durch die Anfangsadressen und einen Namen dazu Felder festlegen, die dann zur Laufzeit benützt werden. Mehr eigentlich nicht. Und erst, wenn wir Befehle schreiben, die diese Daten verwenden, ergibt sich daraus ein Datentyp. Vorher sind das einfach nur Bytes.

Das ist bei Hochsprachen anders: Schon in der Source legen wir durch verschiedene Angaben den Datentyp (char, integer, etc.) fest und daraus entscheidet dann der Compiler, welche Maschinen-Instruktionen er dafür verwenden wird. Wir können das nurmehr eingeschränkt beeinflussen.

===Daten im SRAM===
<pre>
.DSEG ; Das ist eine Datensegment, d.h. es werden SRAM-Adressen festgelegt
CharBuf: .byte 24
OtherData: .byte 4
....
</pre>
'''Anmerkung:''' Standardgemäß beginnt der Assembler mit der kleinsten SRAM Adresse. Bei den meisten AVRs ist das die tatsächliche Byte-Adresse 0x0060 (d.i. 96 dezimal).
[[Atmel_Controller_Mega16_und_Mega32#Adressen_Mapping|Siehe Adress-Mapping]]

Dadurch, daß wir geschrieben haben ".byte 24" bestimmen wir, daß als nächste Datenadresse automatisch dann 96 + 24 = 120 gilt. Also ist mit "OtherData" dann 0x0078 (dez. 120) verknüpft.

'''Noch eins:''' Wir haben ja gesagt, für den Assembler ist alles letztlich eine Zahl. Wir können daher auch damit rechnen. Wenn wir also die "24" nicht selbst wo hinschreiben wollen, verwenden wir einfach den Ausdruck
LDI R10 , Otherdata - CharBuf
und laden damit das Register 10 mit der Zahl 24

===Daten im FLASH (Literale)===
Literale sind Werte, die schon in der Source festgelegt werden können. Das geht im Prinzip ähnlich, nur müssen wir nun auch Datentypen festlegen
<pre>
OneByte: .db 1 ; ein byte mit dem inhalt 0x01
MeinName: .db "Sepp Meier" ; mehrere Bytes mit Text
OneWord: .dw 1,2 ; zwei WORDs (16 Bit) mit dem inhalt 0x0001 u. 0x0002
....
</pre>

Diese Definitionen können wir auch direkt in den Programmcode reinmischen. Wir müssen aber natürlich schauen, daß der AVR zum Laufzeitpunkt nicht versucht, diese Zeichen als Befehl auszuführen.

===Daten im EEPROM (ERAM)===
genauso geht es, wenn man für den EEPROM feste Werte vorgeben will:
<pre>
.ESEG ; Das ist ein EEPROM-Segment
OneByte: .db 1 ; ein byte mit dem inhalt 0x01
MeinName: .db "Sepp Meier" ; mehrere Bytes mit Text
OneWord: .dw 1,2 ; zwei WORDs (16 Bit) mit dem inhalt 0x0001 u. 0x0002
....
</pre>

==Verzweigungen==
Es gibt zwei Arten, bedingte Programm-Sprünge zu formulieren:
* Durch irgendwelche Befehle, meistens durch Vergleichsoperationen, erst die Bits im Statusregister (SREG) zu setzen, und diese Status-Bits abzufragen und je nachdem einen Programmsprung durchzuführen oder nicht.
* Man kann aber auch abhängig von Datenbits in GPRs und SFRs den Folgebefehl überspringen (Skippen) lassen. Dieser Folgebefehl kann, muß aber nicht, ein Sprung- oder Callbefehl sein.

==Zusammenfassung==
Da dieser Artikel kein Assembler Tutorial sein kann und soll, soll hier auf die "eigentlichen" Instruktionen nicht eingegangen werden. Ich wollte nur versuchen, die "Denkweise" des Assembler und der AVR-Micros ein wenig näherzubringen und einige ermuntern, doch die ersten Operationen direkt am offenen Herzen des Kontrollers zu wagen.

In manchen Fällen habe ich aber sicher einige Leser endgültig verschreckt.

==Noch ein Tip==
Gut abgeschrieben ist am Anfang besser als schlecht ausgedacht. Gerade die verschiedenen Geräte-Initialisierungen (SFR) in den zahlreichen GCC Codeschnipsel können fast direkt abgeschrieben werden (Baudrate, Input/Output, etc), da der C-Compiler das ja auch nicht anders machen kann.

==Autor==
[[User:PicNick|PicNick]]

==Weblinks==
[http://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=11488 Ausführlicher Foren-Beitrag zum Thema Assembler-Programmierung] – Lang aber lehrreich
==Siehe auch==
*[[AVR]]
*[[Sourcevergleich]]
*[[GNU Assembler]]
*[[Assembler_Einf%C3%BChrung_f%C3%BCr_Bascom-User|Assembler Einführung für Bascom-User]]
[[Kategorie:Microcontroller]]
[[Kategorie:Robotikeinstieg]]
[[Kategorie:Software]]
[[Kategorie:Quellcode Assembler AVR]]