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

Benutzer Diskussion:Frank

2006-01-05T15:49:49Z

Nollsen:

== Kategorien ==

Hi,

die Kategorie AVR war schon angelegt nur nicht vollständig.

--[[Benutzer:Nollsen|Nollsen]] 16:47, 5. Jan 2006 (CET)

PS: Es gibt einige Kategorien eher zu streichen wären als die AVR Kategorie

Benutzer Diskussion:Frank

2006-01-05T15:47:16Z

Nollsen: Kategorien

== Kategorien ==

Hi,

die Kategorie AVR war schon angelegt nur nicht vollständig.

--[[Benutzer:Nollsen|Nollsen]] 16:47, 5. Jan 2006 (CET)

Diskussion:Leiterplatten herstellen - Toner-Transfer-Methode

2006-01-03T19:35:04Z

Nollsen:

Hallo,

habe mich auch lange mit der Bügelmethode herumgeschlagen, mein Fazit: Belichten geht 100x besser.

Mfg --[[Benutzer:Nollsen|Nollsen]] 20:35, 3. Jan 2006 (CET)

PS: Werde bei Bedarf Bauanleitungen für Ätzmaschinen etc einbringen

AT90S2313

2006-01-03T19:33:02Z

Nollsen: /* Weblinks */ Kategorie AVR

'''Versorgungspannung:'''
::AT90S2313-4: 2.7V-6V
::AT90S2313-10: 4V-6V
'''Flash-Programm-Speicher:''' 2kByte <br>
'''EEPROM-Datenspeicher:''' 128Byte <br>
'''SRAM-Datenspeicher:''' 128 Byte <br>
'''Taktfrequenz:'''
::AT90S2313-4: bis 4MHz
::AT90S2313-10: bis 10MHz
'''Features:'''
* Full Duplex UART
* ein 8-bit Timer
* ein 16-bit Timer mit PWM, InputCapure, external Clock
* Analog-Comparator
* 15 digitale I/O-Ports
* programmierbarer Watchdog-Timer

Der AT90S2313 ist heute veraltet. Der Hersteller empfiehlt, für neue Designs den ATTiny2313 zu verwenden.

http://www.roboternetz.de/wiki/uploads/Main/at902313.gif

==Siehe auch==
* [[Atmel]]
* [[Avr]]

== Packages==
* PDIP 20
* SOIC 20

==Weblinks==
* [http://www.atmel.com/dyn/resources/prod_documents/DOC0839.PDF Datenblatt des AT90S2313 (englisches PDF, 92 Seiten, 1.6 MByte)]
* [http://www.atmel.com/dyn/resources/prod_documents/doc4298.pdf AVR091: Replacing AT90S2313 by ATtiny2313 (englisches PDF, 11 Seiten, 118 kByte)]

[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Grundlagen]]
[[Kategorie:Elektronik]]

AVR Assembler Einführung

2006-01-03T19:32:46Z

Nollsen: /* Siehe auch */ Kategorie AVR

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

* 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 Pointers 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 2<sup>4</sup> 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'''
| '''ARG<sub>1</sub>'''
| '''ARG<sub>2</sub>'''
|}
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: PicNick

==Siehe auch==
*[[Avr]]
*[[Sourcevergleich]]
[[Kategorie:AVR]]
[[Kategorie:Robotikeinstieg]]
[[Kategorie:Software]]

ATmega128

2006-01-03T19:32:43Z

Nollsen: /* Siehe auch */ Kategorie AVR

Sehr leistungsstarker Atmel Controller. Da jedoch derzeit nur als [[SMD]]-Ausführung erhältlich, ist er fr Hobbybastler schwierig zu löten bzw. zu entlöten. Daher ist er noch relativ wenig unter Bastlern verbreitet.

*ATMega AVR 128
*Gehäuse: TQFP-64
*MHz: 16
*Flash: 128
*EEProm: 4K
*RAM: 4K
*I/ O: 53

http://www.roboternetz.de/wiki/uploads/Main/mega128pinbelegung.gif

==Siehe auch==
* [[Avr]]
* [[Atmel]]

[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Grundlagen]]
[[Kategorie:Elektronik]]

ATmega8

2006-01-03T19:32:40Z

Nollsen: /* Siehe auch */ Kategorie AVR

* ATMega AVR 8-16 PDIP
* Gehäuse: DIL-28
* MHz: 16
* Flash: 8
* EEProm: 512
* RAM: 1K
* I/ O: 23

[[Bild:Pinbelegungmega8.gif|center]]

==Siehe auch==
* [[Atmel Controller Mega48 Mega88 Mega168]] - Mega8 Pinkompatibel
* [[Atmel]]
* [[Avr]]
* [[AVR-Einstieg leicht gemacht]]

[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Grundlagen]]
[[Kategorie:Elektronik]]

ATmega16 ATmega32 ATmega644

2006-01-03T19:32:38Z

Nollsen: /* Siehe auch */ Kategorie AVR

== Merkmale und Pinbelegung ==

*ATMega AVR 16/32
*Gehäuse: DIL-40
*MHz: 16
*Flash: 16/32 kB
*EEProm: 1 kB
*RAM: 2 kB
*I/ O: 32

[[Bild:Mega1632.gif|center]]

== Einfache Grundschaltung ==

[[Bild:avrtutorial_grundschaltung_mitquarz.gif|center|500px]]

Weitere Grundschaltungen im Artikel [[AVR-Einstieg leicht gemacht]]

----

==Internes zum Atmega32==

Wenn man das erste Mal mit solchen komplizierten Geräten wie Micro-Controllern konfrontiert wird, kann es schon sein, daß man vor Ehrfurcht erschaudert. Und auch wenn man von Bits und Bytes durchaus eine Ahnung hat, ist allein schon der Umfang des Datasheets möglicherweise abschreckend.
Es soll hier versucht werden darzustellen, daß die ganze Sache nun so schlimm auch wieder nicht ist, wenn man sich den Aufbau eines typischen Vertreters der ATMEL Microcontroller etwas näher betrachtet.

===Architektur Überblick===

[[Bild:Avr.jpg]]Quelle:www.atmel.com

Dieses Bild stammt aus dem Datasheet. Das haben wir wohl schon alle mal gesehen, und vermittelt dem Anfänger eigentlich nur, daß in dem Chip offenbar eine Menge Zeugs drinnen ist. Und da die meisten Pfeile in beide Richtungen zeigen, kann man sich auch nicht recht vorstellen, was da eigentlich in welcher Folge abläuft.

===CPU===
Das "Herz" des Controllers ist im mittleren Bereich links, das ist die "CPU" (= Zentral-Processor). Von hier aus wird all das Drumherum gesteuert, hier landet das Programm, das wir mit mit irgendeinem Compiler erstellt haben.

[[Bild:Avrcpu.jpg]]Quelle:www.atmel.com

Der Rest von dem ganzen Atmega32 ist die "Peripherie", das sind eine Reihe von Einzelgeräten, die alle ihre speziellen Funktionen und Aufgaben haben. Da liegen auch hauptsächlich die Unterschiede zwischen den verschiedenen Micro-Controllern, denn ein kleiner (Tiny) hat weniger solche Geräte und braucht dadurch natürlich auch weniger Pins.

Sehr ähnlich, wenn nicht identisch, ist bei allen AVR-Controllern diese CPU aufgebaut, daher ist es zum Verständnis unerlässlich, sich damit näher zu beschäftigen.

====Program Flash====
Was da so ein kleines Kästchen ist, das ist der Programmspeicher, der beim Atmega32 immerhin 32k groß ist.
====Program Counter====
(=Befehlszähler) beinhaltet IMMER die Adresse des nächsten Befehls im Programmspeicher
====Instruction Register====
hier landet der Inhalt des Programmspeichers von der Adresse "Befehlszähler" immer zuerst, da ja der AVR erstmal selber gucken muß, was für ein Befehl das wohl ist.
Jedes Befehlswort beinhaltet (kodiert) drei Dinge: "WAS", "WOHER" und "WOHIN".
Einiges kann direkt im SRAM oder in den Register eine Auswahl treffen, einiges muß weiter zum
====Instruction Decoder====
Je nach Befehl müssen Datenrichtungen eingestellt werden, und etliche Schalter bedient werden. (CONTROL-LINES)
====SRAM====
Das ist der frei verwendbare Schreib- und Lesespeicher, beim Atmeg32 2k (2048 Byte)
====Stack Pointer====
Der "Stapel-Zeiger" kann ausschlißlich den SRAM adressieren. Aber dazu kommen wir noch

====General Purpose Register (GPR)====
Wie der Name sagt, das sind 32 Bytes für den allgemeinen Gebrauch. Bezeichnet werden sie als R0 (Addresse $0000) bis R31 (Addresse $001F). Die meisten Maschinenbefehle des AVR beziehen sich darauf, wobei einige Unterschiede zwischen R0 - R15 und R16 - R31 gemacht werden.
R26 bis R31 können auch als Pointer-Register X, Y u. Z mit ein paar Extras verwendet werden.
[[Bild:Avrgpr.jpg]]Quelle:www.atmel.com

====ALU====
Arithmetische-Logische-Einheit. Die Register R0 - R31 können ihre Werte da anlegen, die ALU macht dann den eigentlichen Befehl damit. Also Addieren, Subtrahieren, usw.
Das Ergebnis landet dann irgendwo in dem gesamten CPU-Bereich, je nachdem, wie eben die Control-Lines vom Decoder eingestellt sind.
Als Nebenprodukt gibt es aber ein paar Bits, die im
====STATUS REGISTER====
landen, wie eben das "ZERO"-Bit, das "CARRY"-Bit usw.

====Adressen Mapping====
Damit es einfacher ist, Input- und Output-Daten immer ins richtige Kästchen reinzutun oder zu holen, gibt das "Address-Mapping". Es wird einfach eine fortlaufende Adresse angegeben, aber je nach Werte-Bereich landet man ganz woanders.
[[Bild:Adrmap.jpg]]
=====REGISTER=====
Das sind die bereits oben erwähnten "Allgemeinen Register" (GPR)
=====I/O=====
Wenn man hier schreibt oder liest, landet man in Wirklichkeit bei den Kontroll-Schaltern von einem der "Peripheriegeräte". Da gibt es zum Beispiel Stellen, wenn man da reinschreibt, verändert man irgendeinen PIN aussen am Controller.
=====SRAM=====
Der auch schon erwähnte frei verfügbare Schreib-und Lesespeicher

===Maschinen-Code===

====Aufbau====
Eine Assembler Source-Zeile, schematisch:
'''Command Argument1 , Argument2''' ; die Argumente sind optionell, je nach Befehl

Jede Instruktion ist (mindestens) 16 Bit (zwei Bytes) breit. Hier ein paar Befehle, die Bits in den Spalten von Bit 15 (MSB) bis Bit 0 (LSB), links nach rechts

[[Bild:Code1.jpg]]

Der Befehle haben nicht einfach eine Nummer von 0 - 65535, wie man vielleicht erwarten würde, sondern die Befehl-Bits sind mit den Argumenten in recht seltsamer Weise gemischt in diese beiden Bytes hineincodiert.
Der Grund ist der, daß die Argumente ja mal mehr, mal weniger Platz beanspruchen, das heißt, für den eigentlichen Befehlscode bleiben u.U. recht wenig Bits übrig.

* Die erste Command-Selektion erfolgt mit den Bits A u. B (s.o.): Im obigen Beispiel steht dort immer "10".
* Dann ist "C" zu prüfen:
Steht dort "0", ist es einer der vier LD/ST Befehle
Ist dort aber "1",
* geht es weiter mit den Bits in den Spalten "D" und "E" (und so fort)

Die beiden Befehle "JMP" und "CALL" kommen mit den 16 Bits garnicht aus, da wird auch das nächste Wort gelesen, das den restlichen Teil der Zieladresse beinhaltet. (Dadurch brauchen sie auch einen Clock-Cycle mehr)

=====Details=====
Schauen wir uns noch ein paar Bits genauer an.
======LD / ST======
Die Bits A, B u. C dienen zu Identifizierung. Zur weiteren Unterscheidung bleiben noch die beiden anderen farbig unterlegten Bits
* 2<sup>7</sup> ==> LD (SRAM --> Register) oder ST (Register --> SRAM)
* 2<sup>3</sup> ==> Pointer-Register Z oder Y
======IN / OUT======
Ob IN oder OUT, entscheidet das Bit 2<sup>11</sup>
======JMP / CALL======
Der einzige Unterschied ist der, ob der aktuelle PC (Program-Count) vor dem Sprung auf den Stack gepusht wird oder nicht (2<sup>1</sup>)

====Mehrere Namen für einen Befehl====
Bei einer Reihe von Befehlen gibt es mehrere Namen für ein und denselben Maschinenbefehl.
Ein Beispiel:
CLR R1 ; (Setze Register 1 auf $00 )
bringt den gleichen Maschinencode wie
EOR R1, R1 ; Register 1 = Register1 "exclusive or" Register1

Besonders im Umfeld des Stausregisters (SREG) kann man fast von einer "Befehlsvermehrung" sprechen. Obwohl es für Setzen, Löschen und Abfragen der Status-Bits entspechenden Maschinencode gibt, tauchen im "Instruction Set" diese Befehle für jedes der Bits einzeln nochmals auf.

''Artikel: PicNick / ergänzt Frank''

==Siehe auch==
* [[Atmel]]
* [[Avr]]
* [[RN-Control]]
* [[AVR-Einstieg leicht gemacht]]

[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Grundlagen]]
[[Kategorie:Elektronik]]
[[Kategorie:Robotikeinstieg]]

ATmega48 ATmega88 ATmega168 ATmega328

2006-01-03T19:32:35Z

Nollsen: /* Siehe auch */ Kategorie AVR

Diese Controllertypen sind bis auf einige spezielle Funktionen pinkompatibel

===Mega8===
*ATMega AVR 8-16 PDIP
*Gehäuse: DIL-28
*MHz: 16
*Flash: 8
*EEProm: 512
*RAM: 1K
*I/ O: 23
*Betriebsspannung: 2.7 - 5.5V

===Mega48===
*ATMega AVR 48-20 PDIP
*Gehäuse: DIL-28
*MHz: 20
*Flash: 4 kByte
*EEProm: 256 Byte
*RAM: 512 Byte
*I/ O: 23
*Betriebsspannung: 1.8 - 5.5V

===Mega88===
*ATMega AVR 88-20 PDIP
*Gehäuse: DIL-28
*MHz: 20
*Flash: 8 kByte
*EEProm: 512 Byte
*RAM: 1024 Byte
*I/ O: 23
*Betriebsspannung: 1.8 - 5.5V

===Mega168===
*ATMega AVR 168-20 PDIP
*Gehäuse: DIL-28
*MHz: 20
*Flash: 16 kByte
*EEProm: 512 Byte
*RAM: 1 kByte
*I/ O: 23
*Betriebsspannung: 1.8 - 5.5V

http://www.roboternetz.de/wiki/uploads/Main/pinbelegungmega8_168.gif

=== Unterschiede zwischen Mega8 und Mega88===

Der Mega88 ist zwar nicht als Ersatz für den Mega8 entwickelt worden.
Aufgrund der Pin-Kompatibilität läßt er sich aber sehr leicht in bestehenden Schaltungen ersetzen.
Einige Besonderheiten müssen dabei bei der Programmierung berücksichtigt werden.

Die wichtigsten Verbesserungen des ATmega88 gegenüber dem ATmega8 im Überblick:

*Schnellere Taktfrequenz bis 20MHz
*Geringerer Energieverbrauch
*Schnellere EEPROM Schreibzugriffe
*On-Chip Deggugging möglich mit DebugWire (über den RESET Pin)
*Pin Change Interrupt auf allen Eingangs Pins
*10bit Auflösung bei allen Analog/Digital Wandler Kanälen
*Timer 0,2 erweitert um PWM und Compare Einheit
*Ausgabe des Systemtaktes auf einen I/O Pin

=== Unterschiede zwischen Mega48, Mega88 und Mega 168===

Die Unterschiede beschränken sich im wesentlichen auf den internen Speicher:

{| {{Blauetabelle}}
|
|'''ATmega48'''
|'''ATmega88'''
|'''ATmega168'''
|-
|FLASH(bytes)
|4096
|8192
|16384
|-
|EEPROM(bytes)
|256
|512
|512
|-
|SRAM(bytes)
|512
|1024
|1024
|-
|Boot Sector Größe(bytes)
|n.v
|256..2048
|256..2048
|-
|FLASH Page Größe(bytes)
|64
|64
|128
|}

==Siehe auch==
* [[Atmel]]
* [[Avr]]

[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Grundlagen]]
[[Kategorie:Elektronik]]

AVR-ISP Programmierkabel

2006-01-03T19:32:33Z

Nollsen: /* Bezugsquellen */ Kategorie AVR

==ISP-Dongle - Programmieradapter günstig selbst bauen==

Um einen Atmel Controller wie Mega32 etc. (z.B. im RN-Board [[RN-Control]] oder [[RNBFRA-Board]]) oder auch einen anderen Atmel Controller programmieren zu können, benötigt man ein spezielles Anschlusskabel mit ein wenig Elektronik. In der Regel hat sich eine Schaltung bewährt, welche am Druckerport des PCs eingesteckt wird.
Hier gibt es zwar auch verschiedene einfache Lösungen die nur mit einigen Widerständen oder Dioden aus kommen, von diesen ist aber abzuraten da ein defektes Board oder ein falsch aufgesteckter ISP Stecker dann schnell die Druckerschnittstelle beschädigen kann.

Besser sind Lösungen mit einem Bustreiber.

Eine bewährte Schaltung, ist folgende:
<center>
http://www.robotikhardware.de/bilder/ispplan.gif
</center>
Eine solche Schaltung schützt den Druckerport er erlaubt die zuverlässige und schnelle Programmierung der meisten Atmel Controller, wahlweise direkt aus dem Basic Compiler Bascom heraus oder mit dem ebenfalls oft genutztem Übertragungsprogramm Pony.

Besonders günstig und einfach lässt sich die Schaltung mit einer speziell geformten Platine aufbauen. Durch die geformte Platine lassen sich nämlich sowohl Stecker als auch Gehäuse sehr leicht montieren. Zudem sind Fehler beim Aufbau der Schaltung fast unmöglich.

Insgesamt benötigt man nur wenige Bauteile:
<center>
http://www.robotikhardware.de/bilder/isp/isp1.jpg
</center>

<pre>
1 Stück Platine (über www.robotikhardware.de für ca. 5,90 Euro erhältlich)
1 Stück Widerstand 100 k
1 Stück Kondensator 100 nF
1 Stück Diode z.B. 1N4148 oder ähnlich
1 Stück IC 74HC244
1 Stück 9 pol SUB D-Buchse
1 Stück 25 pol SUB D-Stecker

1 Stück 9 pol SUB D Stecker zum aufpressen auf Flachkabel
1 Stück 10pol Wannenstecker zum aufpressen auf Flachkabel
1m Flachkabel 9 polig
1 Stück Universal Sub D-Gehäuse
</pre>

Der 1 Schritt besteht darin das man gleich alle Bauteil in die Platine einsteckt und so biegt, das diese beim umdrehen und einlöten nicht herausfallen.

<center>
http://www.robotikhardware.de/bilder/isp/isp2.jpg
</center>

Das Löten ist eigentlich bei den wenigen Bauteilen keine groß Kunst und sollte von jedem Laien in wenigen 2 Minuten erledigt sein.

<center>
http://www.robotikhardware.de/bilder/isp/isp3.jpg
</center>

Nun werden die SUB-D Stecker einfach direkt auf die Platine gesteckt. Und zwar so, das die Platine genau zwischen der oberen und unteren Reihe liegt. Dabei sollte man darauf achten das die Kontakte auf den verzinnten Lötflächen liegen.

<center>
http://www.robotikhardware.de/bilder/isp/isp4.jpg
</center>

Am besten legt man die Platine mit den aufgesteckten Steckern schon einmal in das Gehäuse um die Passgenauigkeit zu überprüfen. Man variiert also gegebenenfalls die Steckerposition um 1 mm falls es noch nicht 100% passt.

<center>
http://www.robotikhardware.de/bilder/isp/isp5.jpg
</center>

Großes Bild [[http://www.robotikhardware.de/bilder/isp/isp6.jpg]]

Jetzt kann man die Kontakte einfach verlöten. Dabei sollte man das Lötzinn etwas neben den Kontakt halten, damit dieses auch darunter fließen kann. Auch das ist in ca. 2 bis 3 Minuten sehr einfach zu erledigen.
Gelötet sieht das ganze dann so aus:

<center>
http://www.robotikhardware.de/bilder/isp/isp7.jpg
</center>

Nun kann man das Gehäuse einfach zusammenstecken. Jetzt benötigen wir aber noch ein Anschlusskabel für das Roboter- bzw. Experimentierboard. Da hie rein 10 poliger Wannenstecker üblich ist, benötigen wir also diesen und ein SUP-D Stecker und etwas Kabel (9 polig).

<center>
http://www.robotikhardware.de/bilder/isp/isp8.jpg
</center>

Besonders einfach lassen sich hier die Stecker nutzen, die man einfach auf das Flachkabel aufpresst. Zuerst wird das Kabel wie auf dem Bild eingelegt und der hintere Teil am Stecker etwas zusamengedrückt.

<center>
http://www.robotikhardware.de/bilder/isp/isp9.jpg
</center>

Eigentlich benötigt man nun eine spezielle Zange um den Stecker gleichmäßig zusammenzudrücken, damit es wirklich gerade in die Adern einschneidet. Aber da nur wenige ein solches Werkzeug besitzen, kann man sich zum Beispiel auch mit einem Schraubstock oder dergleichen behelfen.

<center>
http://www.robotikhardware.de/bilder/isp/isp10.jpg
</center>

Wichtig ist nur das man die Stecker gleichmäßig und langsam zusammendrückt.

Auf der anderen Seite montieren wir nun auf die gleiche Weise den 10 poligen Wannenstecker. Dabei ist darauf zu achten das Pin 1 (der rot markierte Draht am Flachkabel) an der Stelle sitzt, wo ein Pfeil auf dem Stecker erkennbar ist.

<center>
http://www.robotikhardware.de/bilder/isp/isp11.jpg
</center>

Auch diesen Stecker kann man mit einem Schraubstock oder Maschinenschraubstock pressen

<center>
http://www.robotikhardware.de/bilder/isp/isp12.jpg
</center>

Das war es schon. Unser perfektes ISP-Kabel ist fertig und sollte so aussehen:

<center>
http://www.robotikhardware.de/bilder/isp/isp13.jpg
</center>

<center>
http://www.robotikhardware.de/bilder/isp/ispstecker.jpg
</center>

==Siehe auch==
*[[RN-Definitionen]]
*[[Avr]]

==Bezugsquellen==
* Platine Shop http://www.robotikhardware.de
* Fertiger Dongle http://www.robotikhardware.de
Bauteile :
* http://www.reichelt.de
* http://www.conrad.de

{{Platinenservice|http://www.robotikhardware.de}}
{{Fertigservice|http://www.robotikhardware.de}}

[[Kategorie:AVR]]
[[Category:Robotikeinstieg]]
[[Category:Praxis]]
[[Category:Elektronik]]
[[Category:Projekte]]

Bascom - Erstes Programm in den AVR Controller übertragen

2006-01-03T19:32:30Z

Nollsen: /* Weblinks */ Kategorie AVR

==Wie ist der Ablauf mit Bascom Basic?==
Atmel Controller (also auch [[RN-Control]]) lassen in verschiedenen Programmiersprachen programmieren. Sehr beliebt sind diesbezüglich der Basic Compiler [[Bascom]], der C Compiler GCC und der AVR Studio Assembler.

Der Einstieg wird einem besonders einfach beim [[Bascom]] Compiler gemacht. Nicht nur dass dieser unzählige von Funktion besitzt, nein auch die Entwicklungsumgebung ist sehr umfangreich. Simulator, [[Terminalprogramm]] und Flasher (Übertragungsprogramm) sowie eine ganze Reihe anderer Tools sind bereits integriert. Zudem erzeugt der Compiler überraschend kompakten Maschinencode.
Es gibt eine kostenlose Demo-Version von [[Bascom]]. Die Einschränkung gegenüber der Vollversion besteht im wesentlichen darin, das nur 4K Code erzeugt werden kann. Dies reicht bereits für viele kleinere Anwendungen aus. Für ca. 90 Euro gibt’s auch eine Vollversion ohne Einschränkung. Fast alle gängigen [[Atmel]]-Controller lassen sich mit Bascom Basic programmieren.

Der Einstieg ist sehr einfach. Nachdem man sich die Demo oder Vollversion besorgt hat, installiert man das Programm über SETUP auf einem Windows-Rechner, dies ist recht unproblematisch.
Das Programm wird anschließend über das START-Menü aufgerufen.

Bevor ein erstes Programm entwickelt wird, sollte man erst mal einige grundsätzliche Optionen in Bascom einstellen. Zum Programmieren eines Controllers benötigt man ein speziellen Adapter welcher einige Leitungen des Controllers (SPI-Ports und RESET) mit dem PC verbindet. Man spricht hier von einem [[AVR-ISP Programmierkabel|AVR-ISP Programmierkabel]] oder auch [[AVR-ISP Programmierkabel|ISP-Dongel]] genannt, dieser wird oft an den Druckerport des PC angeschlossen.

Beispiel eines ISP-Programmierkabels (hier [[AVR-ISP Programmierkabel|Bauanleitung]]):

[[Bild:avrtutorial_ispkabel.jpg|center]]

Verwendet man ein solches Kabel, so sollte man in Bascom folgende Optionen einstellen:

<center>
http://www.roboternetz.de/bilder/bascom/bascomispoptionen.gif
</center>

Diese Optionen bleiben dauerhaft gespeichert und müssen nicht bei jedem neuen Programm geändert werden.

Nun müssen noch die Output-Optionen in [[Bascom]] festgelegt werden. Bascom ist in der Lage eine ganze Reihe von verschiedenen Dateien zu generieren um später verschiedene Programmiertools und Debugger nutzen zu können. Empfehlenswert ist folgende Grundeinstellung:

<center>
http://www.roboternetz.de/bilder/bascom/bascomoutputoptionen.gif
</center>

===Das erste Programm===

Über das Menü File/New kann dann ein neues Fenster für ein erstes Bascom-Programm geöffnet werden.
Als erstes Einstiegsprogramm könnte ein "Hello World"-Programm so aussehen:

Print "**** RN-CONTROL sagt Hello World *****"

Dieses Programm würde allerdings kaum funktionieren, außer wenn man unter Optionen den Controllertyp, die genaue Quarzfrequenz und Baudrate des verwendeten Controllers (Controllerboard´s) richtig eingestellt hat.

Es ist allerdings empfehlenswert diese Werte lieber im Programmcode mit festzulegen. Dadurch hat man eine wesentlich bessere Übersicht und kann die Programme auch leichter, ohne zusätzliche Kommentare, an interessierte weitergeben. Eventuell vorhandene Einstellungen im Optionsmenü werden durch die Anweisungen im Code außer Kraft gesetzt.
Im Falle von dem Microcontrollerboard [[RN-Control]] mit AVR [[ATMega32]] sollte daher jeder Quelltext mit folgenden Zeilen beginnen:

$regfile = "m32def.dat"
$framesize = 32
$swstack = 32
$hwstack = 32
$crystal = 16000000
$baud = 9600
do
Print "**** RN-CONTROL sagt Hello World *****"
wait 1
loop

Die erste Anweisung $regfile legt fest für welchen Controllertyp überhaupt Code produziert werden soll. Die Anweisungen $framesize, $swstack, $hwstack sind eigentlich bei dem kleinen Programm nicht notwendig. Sie legen den Platz fest, der für bestimmte Stackbereiche (lokale Variablen / Funktionsparameter) reserviert wird. Man sollte sich jedoch gleich angewöhnen diese Anweisungen in den Code zu schreiben. Das ermitteln der richtigen Werte für die Stackgröße ist etwas aufwendiger, dazu bietet Bascom spezielle Funktionen für den Simulator. In der Regel kommt man aber mit den oberen Werten schon bei den meisten Programmen hin. Im Zweifel sollte man die Werte etwas erhöhen. Je höher die Werte, desto mehr Speicher wird natürlich benötigt. Zu geringe Werte können aber unter Umständen, wenn z.B. viele Subroutinen, Funktionen, Interrupts, lokale Variablen genutzt werden, zu seltsamen schwer auffindbaren Programmfehlern führen.
Wenn also eine Funktion völlig unsinnige Ergebnisse liefert oder Abstürze erfolgen, dann ist es Zeit den Stack mal zu prüfen.

Die Anweisung $crystal legt die Quarzfrequenz fest. Es ist wichtig dass Bascom weiss mit welcher Quarzfrequenz der Controller arbeitet, ansonsten liefern viele Funktionen falsche Ergebnisse oder funktionieren erst garnicht. Anzumerken ist hier, das [[AVR]] Controller der Mega Serie (wie der [[ATMega32]] in [[RN-Control]]) nach dem Kauf noch gar keinen Quarz sondern den internen Taktgenerator nutzen. Der interne Taktgenerator läuft immer mit 1 Mhz, so dass man bei neuen Controllern eigentlich $crystal=1000000 angeben müsste. Zumindest solange bis man den Quarz über die sogenannten Fusebits (bestimmte Einstellungen im Controller) aktiviert.
Da in diesem Beispiel jedoch das Board [[RN-Control]] gleich auf die vollen 16 Mhz umgeschaltet werden soll, geben wir gleich $crystal = 16000000 an.

Die Anweisung $baud = 9600 bestimmt die Übertragungsgeschwindigkeit der RS232 Schnittstelle im Controller. 9600 Baud ist ein Wert der sehr oft genutzt wird. Da ein Controller ja kein Bildschirm besitzt, erfolgen alle Ausgaben gewöhnlich über diese RS232 Schnittstelle. Man muss also nur das eingebaute [[Terminalprogramm]] in [[Bascom]] starten und kann dann alle Ausgaben des angeschlossenen Controllers am Bildschirm verfolgen. Dies ist sehr hilfreich bei der Fehlersuche in Programmen, daher gehört neben dem [[AVR-ISP Programmierkabel]] eigentlich auch immer ein RS232-Kabel zur Standard Ausstattung eines Programmierers.

Nachdem nun der Quellcode erstellt wurde muss dieser compiliert (in Maschinencode übersetzt) werden. Dies geschieht durch einen einfachen Klick:

<center>
http://www.roboternetz.de/bilder/bascom/bascomcompilieren550_a.gif
</center>

Hat man noch einen Fehler im Quellcode, dann steht nun gewöhnlich im unteren Bereich eine Fehlermeldung, ansonsten dürfte ein Fenster ähnlich wie dieses erscheinen:

<center>
http://www.roboternetz.de/bilder/bascom/bascomcompiliermsg_b.gif
</center>

Dieser Vorgang dauert oft nur wenige Sekunden, danach ist das Maschinencodeprogramm fertig. Damit es ausgeführt werden kann, muss es natürlich in den Controller übertragen werden. Dazu verbindet man das Controllerboard über ein ISP-Programmierkabel mit dem Druckerport des PC´s. Zudem schaltet man die Betriebsspannung des Baords ein. Nun kann der Bascom Programmiermodus durch einen Klick aktiviert werden:

<center>
http://www.roboternetz.de/bilder/bascom/bascomprgaktivieren550_c.gif
</center>

Im Bascom Programmiermodus wird der Maschinencode in Hex-Form angezeigt. In diesem Dialog brauchen wir eigentlich nur die Übertragung zu starten. Dies geschieht wiederum durch einen Klick:

<center>
http://www.roboternetz.de/bilder/bascom/bascomispstart550_d.gif
</center>

Auch die Übertragung dauert nur wenige Sekunden. Wenn alles geklappt hat sollte in der Statuszeile links "OK" stehen. Leider ist die ISP Übertragung manchmal etwas störanfällig so das man einen zweiten oder dritten Versuch braucht. Kommt dies öfters vor, sollte man prüfen ob nicht ein Netzkabel oder eine andere Störquelle das ISP Kabel kreuzt.

Nachdem man das Programm übertragen hat, muss man bei einem neuen Controller noch die sogenannten Fusebit´s umschalten. Unter dem Begriff Fusebit´s versteht man bestimmte Controllereinstellungen die ebenfalls über das ISP-Programmierkabel geändert werden können. Es gibt eine ganze Reihe von Einstellungen die man verändern kann, dies ist bei jedem Controller ein wenig anders. gewöhnlich reicht es jedoch den Quarz zu aktivieren und ein soganannten JTAG-Interface zu deaktivieren. Das JTAG-Interface ist ein spezielles Debugger-Interface um Programmfehler zu finden, es kann jedoch nur genutzt werden wenn man spezielle Zusatzhardware besitzt. Da dies selten der Fall ist kann man diese Port´s auch für andere Zwecke nutzen, daher wird dieses oft deaktiviert.
Um die Fusebit´s nun zu ändern rufen wir im Programmierdialog die Tafel mit den [[Fusebits]] durch einen klick auf:

<center>
http://www.roboternetz.de/bilder/bascom/bascomfusebitdialog550_e.gif
</center>

Der Controller muss beim Aufruf dieses Dialoges angeschlossen und mit Strom versorgt werden.
Nun können wir die [[Fusebits]] an zwei Stellen ändern. Dies geht in [[Bascom]] sehr bequem, da wir in zwei Feldern nur eine andere Auswahl treffen müssen, siehe Bild:

<center>
http://www.roboternetz.de/bilder/bascom/bascomquarz550_f.gif
</center>

Beim Quarz ist es meist die unterste Auswahlmöglichkeit. Die [[Fusebits]] sind also richtig eingestellt wenn es wie auf dem oberen Bild aussieht. Bei dem Board [[RN-Control]] sind diese Einstellungen in der Regel nicht notwendig da diese bereits vor der Auslieferung umgestellt werden.
Die Fusebits müssen auch nur einmal umgestellt werden. Die Einstellungen bleiben auch erhalten wenn ein neues Programm eingespielt wird.
Nicht vergessen dass nach der Änderungen der Fusebit-Auswahl diese auch über den Button "WRITE FS" und "WRITE FSH" in den Controller übertragen werden müssen.

Vorsicht: Vor der Übertragung darauf achten dass die richtigen Quarzeinstellungen gewählt wurden. Man kann den Controller dort nämlich auch auf aktive externe Taktgeneratoren umstellen. Wenn man dies versehentlich tut und keinen echten Taktgenerator hat, dann ist der Controller quasi tot und muss gewechselt werden.

Mit der Programmübertragung wird gleichzeitig auch immer ein RESET ausgeführt und das Programm im Controller gestartet. Wenn Sie nun also das Terminalprogramm in Bascom starten (Parameter 9800 baud, 8 Bit, 1 Stopp Bit), dann wird im Sekundentakt ''**** RN-CONTROL sagt Hello World *****'' erscheinen.

'''Nun viel Spaß beim Einstieg'''

==Autor==
* Frank

==Siehe auch==
*[[Bascom]]
*[[AVR-ISP Programmierkabel]]
*[[RN-Board FAQ-Seite]]
*[[Atmel]]
*[[RN-Control]]
*[[AVR-Einstieg leicht gemacht]]
*[[Buchvorstellungen]]

==Weblinks==
[http://www.roboternetz.de/phpBB2/viewforum.php?f=32 Bascom-Forum]
[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Software]]
[[Kategorie:Grundlagen]]
[[Kategorie:Praxis]]
[[Kategorie:Robotikeinstieg]]

Bascom Inside

2006-01-03T19:32:27Z

Nollsen: /* Siehe auch */ Kategorie AVR

==Bascom Inside==
===Stacks & Frame===
Bascom arbeitet mit drei Bereichen:
* HW-Stack,
* Software-Stack und
* Frame.
Beschrieben ist das im „HELP“.
Zusätzlich wird noch das
* Register r6 für spezielle Flags verwendet (Bit #2 im Register 6 ist das ERR-Bit)

[[Bild:Stack1.jpg]]

====Hw-(Hardware-)Stack====
Der Hardware-Stack ist sozusagen der "normale" Stack, der von den Controllern durch den Stack-Pointer und entsprechende Befehle unterstützt wird.
BasCom verwendet ihn natürlich für CALL / RET / RETI / PUSH und POP.
====Sw-(Software-)Stack====
Für Pointer auf temporäre Daten und die Parameter für SUB und FUNCTION hat BasCom einen eigenen Stack definiert. Er liegt unterhalb des Hardwarestacks.
====Frame====
Für die temporäre Daten selbst wird der Frame-Bereich verwendet

===Definition===
$framesize = 32 ' die Größe des Frames
$swstack = 32 ' die Größe des Software-stacks
$hwstack = 32 ' die Größe des Hardware-Stacks

Die tatsächlich benötigten Größen sind schwer zu errechnen.
Einige Anhaltspunkte:
* Bei jedem Interrupt werden schon mal 32 Byte HW-Stack sicher verbraten, nur, um alle Register zu sichern.
* Jedes "LOCAL" Data verbraucht Frame-Space in seiner Größe + 2 byte auf dem Soft-Stack
* Jeder Parameter einer "SUB" braucht 2 Byte SoftStack + die Datengröße, wenn zusätzlich "byval" angegeben ist.
* datenkonversionen Zahl --> string brauchen die Stringlänge ( PRINT !)

Für ein anständiges Programm sind die Default-Werte auf jeden Fall viel zu klein.
Im Zweifelsfall so groß wie möglich, besonders der SoftStack.

===Lokale Daten===

Für lokale Daten muß natürlich erstmal ein Platz geschaffen werden. BasCom verwendet dazu das Frame, die Adresse der Daten legt er auf den Software-Stack.
Alle Datentypen werden gleich behandelt, nur die reservierte Byte-Länge ist relevant.
BasCom schreibt die erforderliche Länge des Items nach R24 und ruft eine interne Function auf.Diese sichert erst den Frame-Pointer (r4:r5) auf dem Software-Stack, erhöht den Frame-Pointer um den verlangten Wert und kehrt zurück

====reserve space====
LOCAL Einbyte AS BYTE

....
LDI r24,$01 // gewünschte Länge = immediate value
CALL AddFrame
....

AddFrame:
ST --Y,r5 // Store & Save Frampointer Hi
ST --Y,r4 // Store & Save Frampointer LO
ADD r4,r24 // addieren der gewünschten Länge auf den FramePointer
CLR r24
ADC r5,r24 // ev. carry - Überlauf
RET

Dadurch befindet sich die Adresse des lokalen Datums auf

Y + 0 // Adresse LSB
Y + 1 // Adresse MSB

und steht dort (natürlich nur innerhalb der Function oder Subroutine) zu Verfügung

====unreserve====
Vor dem "Return" der Subroutine oder Function muß natürlich alles wiederhergestellt werden
BasCom hat natürlich mitgezählt, wieviel Platz benötigt wurde, und er weiß auch, wieviele solcher Adressen er auf den Soft-Stack gelegt hat.

…..
ADIW YL,$0002 // Addieren auf den Software Stack Pointer
LDI r24,$01 // Subtrahieren vom Frame Pointer (z.b. 1 Byte )
CALL SubR4
RET // return Sub or Function

SubR4:
SUB r4,r24
CLR r24
SBC r5,r24
RET

===Call Sub & Function===

Die Parameter an die Funktion / Sub werden über den Softstack übergeben.
Außer für den eigentlichen CALL der Function / Sub wird der HW-Stack hier nicht verwendet.

Es gibt an sich zwei Übergabe-Varianten: BYVAL und BYREF, es wird aber immer BYREF (Addresse von) verwendet, der Unterschied liegt nur darin, dass bei
BYVAL die Addresse einer Daten-Kopie statt des Originals übergeben wird. Die Reihenfolge ist von links nach rechts, wobei die Adresse des Ergebnisses (Funktion)
als erstes auf den Soft-Stack gelegt wird wird.

'''Folgenden Deklarationen führen im Programm zum gleichen Code'''
Declare Function MyFunc (byval Op1 as byte, byval Op2 as byte) as byte
Declare Sub MySub (byref Result as byte , byval Op1 as byte, byval Op2 as byte)

Die Situation beim Aufruf der Funktion / Sub sieht nun folgendermaßen aus, den HW-Stack nicht berücksichtigend

[[Bild:Stack2.jpg]]

Die Funktion / Sub findet nun (beim Entry)

OP2 auf Y + 0/1
OP1 auf Y + 2/3
Result auf Y + 4/5

Verwendet die Funktion / Sub nun selbst den SW-Stack oder das Frame, muß sie das natürlich bei den Y-Offsets berücksichtigen und vor dem Return muß der obige
Zustand auch wiederhergestellt werden.

==Siehe auch==
* [[Bascom]]
[[Kategorie:AVR]]
[[Kategorie:Grundlagen]]
[[Kategorie:Software]]

Bascom

2006-01-03T19:32:23Z

Nollsen: /* Literatur */ Kategorie AVR

==AVR Bascom Basic==

Bascom ist eine komplette Basic-Entwicklungsumgebung für die verschiedensten AVR Controller.Er bietet ein ungeheuer großes Leistungsvermögen und besonders anwenderfreundliche Entwicklungsumgebung.
Eine kostenlose Version, die bis zu 4 KB (das ist schon einiges bei einem Controller) keinerlei Einschränkungen besitzt, findet man auf der Seite des Herstellers

[http://www.mcselec.com/index.php?option=com_docman&task=cat_view&gid=99&Itemid=54 Bascom-Download]

Nach dem Download müssen alle Dateien entpackt und das SETUP-Programm aufgerufen werden. Danach steht ein Basic-Entwicklungssystem zur Verfügung das alles beinhaltet was für die AVR-Programmierung notwendig ist. Zum Beispiel: Editor mit Befehlsvorschlag, Simulator, Terminalprogram, Avr-FuseBit Einstellung, integriertem Assembler, eingebauten Programmer zur Übertragung des Programmcode usw.

Als erstes solltet ihr unter dem Menü Options / Compiler den Zielprozessor angeben. Fast alle gängigen AVR Controller können programmiert werden.
In diesem Dialog können auch noch viele weitere Einstellungen vorgenommen werden. Eigentlich ist das alles selbsterklärend.

http://www.shop.robotikhardware.de/shop/catalog/images/artikelbilder/bascom/bascom.gif

==Befehlsübersicht von Bascom==

<pre>
Decision and structures:
IF, THEN, ELSE, ELSEIF, END IF, DO, LOOP, WHILE, WEND, UNTIL,
EXIT DO, EXIT WHILE, FOR, NEXT, TO, STEP, EXIT FOR,
ON .. GOTO/GOSUB, SELECT, CASE.

Input and output:
PRINT, INPUT, INKEY, PRINT, INPUTHEX, LCD, UPPERLINE, LOWERLINE,
DISPLAY ON/OFF, CURSOR ON/OFF/BLINK/NOBLINK, HOME, LOCATE,
SHIFTLCD LEFT/RIGHT, SHIFTCURSOR LEFT/RIGHT, CLS, DEFLCDCHAR, WAITKEY,
INPUTBIN, PRINTBIN, OPEN, CLOSE, DEBOUNCE, SHIFTIN, SHIFTOUT,
GETATKBD, SPC, SERIN, SEROUT

Numeric functions:
AND, OR, XOR, INC, DEC, MOD, NOT, ABS, BCD, LOG, EXP, SQR, SIN,COS,
TAN,ATN, ATN2, ASIN, ACOS, FIX, ROUND, MOD, SGN, POWER, RAD2DEG,
DEG2RAD, LOG10, TANH, SINH, COSH.

I2C:
I2CSTART, I2CSTOP, I2CWBYTE, I2CRBYTE, I2CSEND and I2CRECEIVE.

1WIRE:
1WWRITE, 1WREAD, 1WRESET, 1WIRECOUNT, 1WSEARCHFIRST, 1WSEARCHNEXT.

SPI:
SPIINIT, SPIIN, SPIOUT, SPIMOVE.

Interrupt programming:
ON INT0/INT1/TIMER0/TIMER1/SERIAL, RETURN, ENABLE, DISABLE,
COUNTERx, CAPTUREx, INTERRUPTS, CONFIG, START, LOAD.

Bit manipulation:
SET, RESET, ROTATE, SHIFT, BITWAIT, TOGGLE.

Variables:
DIM, BIT , BYTE , INTEGER , WORD, LONG, SINGLE, DOUBLE, STRING , DEFBIT,
DEFBYTE, DEFINT, DEFWORD.

Miscellaneous:
REM, ' , SWAP, END, STOP, CONST, DELAY, WAIT, WAITMS, GOTO, GOSUB,
POWERDOWN, IDLE, DECLARE, CALL, SUB, END SUB, MAKEDEC, MAKEBCD,
INP,OUT, ALIAS, DIM , ERASE, DATA, READ, RESTORE, INCR, DECR, PEEK,
POKE, CPEEK, FUNCTION, READMAGCARD, BIN2GRAY, GRAY2BIN, CRC8, CRC16,
CHECKSUM.

Compiler directives:
$INCLUDE, $BAUD and $CRYSTAL, $SERIALINPUT, $SERIALOUTPUT, $RAMSIZE,
$RAMSTART, $DEFAULT XRAM, $ASM-$END ASM, $LCD, $EXTERNAL, $LIB.

String manipulation:
STRING, SPACE, LEFT, RIGHT, MID, VAL, HEXVAL, LEN, STR, HEX,
LTRIM, RTRIM, TRIM, LCASE, UCASE, FORMAT, FUSING, INSTR.
</pre>

==Erläuterung grundlegender Bascom-Funktionen==
Hier einige kleine Programme welche die grundlegende Funktionen und Syntax zeigen. Es wird immer ein komplettes Programm gezeigt, so das man dieses einfach kopieren und austesten kann. Bascom Programme bestehen in der Regel fast immer nur aus einer Sourcecode-Datei (obwohl es auch anders geht), also nicht wie bei der Programmiersprache C üblich aus mehreren Dateien (Header-Dateien etc.). Auch das macht Bascom besonders Einsteigerfreundlich.

===Das berühmte Hello World Programm in Bascom===
Da bei einem Controllerboard gewöhnlich kein Bildschirm zur Verfügung steht, verbindet man das Board über einfaches RS232 Kabel (nur 3 Drähte sind notwendig) mit dem PC. Ein [[Terminalprogramm]] (Bascom hat bereits eines in der Entwicklungsumgebung integriert) zeigt nun auf dem Bildschirm alle Ausgaben des Boardes (z.B. des Print Befehles) an. Eine Methode die zum Debuggen von Programmen oft genutzt wird.

<pre>
$regfile = "m32def.dat" 'Die Anweisung bestimmt Ccntrollertyp, hier AVR Mega 32
$framesize = 32 'Stackanweisungen, die eigentlich nur bei größeren Programmen
$swstack = 32 'wirklich nötig werden
$hwstack = 32
$crystal = 16000000 'Die Frequenz des verwendeten Quarzes

$baud = 9600 'Die Baudrate für RS232 Ausgabe.
'Sie muss auch bei PC Terminalprogramm identisch sein
do
Print "**** RN-CONTROL sagt Hello World *****"
wait 1
loop
</pre>

===Einen I/O Port umschalten===
Die wohl wichtigste Aufgabe beim Controller ist die Programmierung der Ports. Also das bestimmen des Ausgangspegels eines Controllerpins.
Bascom verfügt über zwei Möglichkeiten die Ports zu beeinflussen, die sogenannten High-Level Befehle und die übliche Registerzuweisung wie sie in C üblich ist.
Zuerst ein Programm mit High-Level Anweisung. Ein [[Pin]] wird als Ausgang definiert und dann fortlaufenden ein und ausgeschaltet. ISt übe rein Wiederstand eine LED an diesem Controllerpin angschlossen (so im Falle von [[RN-Control]]), so ergibt sich ein blinken

<pre>
$regfile = "m32def.dat" 'Die Anweisung bestimmt Controllertyp, hier AVR Mega 32
$framesize = 32 'Stackanweisungen, die eigentlich nur bei größeren Programmen
$swstack = 32 'wirklich nötig werden
$hwstack = 32
$crystal = 16000000 'Die Frequenz des verwendeten Quarzes

$baud = 9600 'Die Baudrate für RS232 Ausgabe.
'Sie muss auch bei PC Terminalprogramm identisch sein

Config Portc.0 = Output 'Ein Pin wird aus Ausgang konfiguriert PC0 (also Pin0 von Port C)

do
Portc.0 = 1 'Pin wird auf High, also 5V geschaltet
Waitms 100
Portc.0 = 0 'Pin wird auf Low, also 0V geschaltet
Waitms 100
loop
</pre>

Man kann das ganze noch etwas übersichtlicher gestalten indem man dem Port-[[Pin]] im Programmcode eine andere Bezeichnung gibt, z.B. LED wie in dem folgenden Beispiel. Durch den Alias Befehl wird das ganze Programm wesentlich klarer, so das einige Kommentarzeilen durchaus entfallen könnten. Man sollte sich daher angewöhnen den Alias Befehl auch zu nutzen

<pre>
$regfile = "m32def.dat" 'Die Anweisung bestimmt Controllertyp, hier AVR Mega 32
$framesize = 32 'Stackanweisungen, die eigentlich nur bei größeren Programmen
$swstack = 32 'wirklich nötig werden
$hwstack = 32
$crystal = 16000000 'Die Frequenz des verwendeten Quarzes

$baud = 9600 'Die Baudrate für RS232 Ausgabe.
'Sie muss auch beim PC Terminalprogramm identisch sein

Config Portc.0 = Output 'Ein Pin wird als Ausgang konfiguriert PC0 (also Pin0 von Port C)
Led Alias Portc.0

do
Led = 1 'Pin wird auf High, also 5V geschaltet
Waitms 100
Led = 0 'Pin wird auf Low, also 0V geschaltet
Waitms 100
loop
</pre>

Das nachfolgende Beispiel kommt ohne den High-Level Befehl CONFIG aus, indem direkt in das Datenrichtungsregister des Controllers geschrieben wird. In diesem Register steht jedes Bit für den Betriebsmode eines Pins. Die 1 bedeutet der Pin ist auf Ausgang geschaltet, 0 bedeutet Eingang. Diese Schreibweise hat den Nachteil das sie ein wenig unübersichtlicher ist, man kann sehr schnell [[Pin]]´s verwechseln. Vorteil ist allerdings das alle 8 [[Pin]]´s eines Portes gleichzeitig mit einer Zuweisung definiert werden können. Es gibt daher Programmierer die diese Methode bevorzugen, insbesondere wenn Sie auch Controller in C programmieren. Das Ergebnis ist in jedem Fall gleich: ein Blinklicht

<pre>
$regfile = "m32def.dat" 'Die Anweisung bestimmt Controllertyp, hier [[AVR]] Mega 32
$framesize = 32 'Stackanweisungen, die eigentlich nur bei größeren Programmen
$swstack = 32 'wirklich nötig werden
$hwstack = 32
$crystal = 16000000 'Die Frequenz des verwendeten Quarzes

$baud = 9600 'Die Baudrate für RS232 Ausgabe.
'Sie muss auch bei PC Terminalprogramm identisch sein

DDRC = &b00000001 'Port PC0 wird als Ausgang definiert, man hätte hier auch
'DDRC =1 schreiben können. Man verwendet aber oft die Bitdarstellung
'um alle 8 Bit besser überschauen zu können

do
Portc.0 = 1 'Pin wird auf High, also 5V geschaltet
Waitms 100
Portc.0 = 0 'Pin wird auf Low, also 0V geschaltet
Waitms 100
loop
</pre>

===I/O-Port als Eingang===
Im nachfolgenden Beispiel möchten wir ein PIN als Eingang verwenden und den Zustand eines Tasters abfragen. Dazu werden die Pole eines Tastes einmal mit GND (Masse) und einmal mit einem Port PA0 verbunden. Wir hätten auch jeden anderen Port nehmen können, da beim [[Avr]] Controller nahezu alle Pin´s auch auf Eingang geschaltet werden können. Der übersichtlichkeit halber verwenden wir wieder den Config und den Alias Befehl um den Port in Taster umzutaufen.
Etwas gewöhnungsbedürftig ist in Bascom das man bei der Definition von Eingangsports nicht PORT sondern PIN beim Config-Befehl angibt. Eine weitere Besonderheit dieses Beispiels ist der Befehl ''Porta.0=1'' beim EIngabeport. Dieser Befehl sorgt dafür das im Controller der EIngangsport über einen hohen Widerstand (ca. 100k) mit High (5V) verbunden wird. Dadurch erreicht man, das bei unbelegtem Port, in unserem Fall ungedrückte Taste, immer ein High Signal gelesen wird. Erst wenn der Taster gedrückt wird, wird diese Spannung quasi kurzgeschlossen und so ein LOW angelegt. Das ganze Beispiel bewirkt nun das bei gedrückter Taste die LED leuchtet und beim loslassen wieder aus geht.

<pre>
$regfile = "m32def.dat" 'Die Anweisung bestimmt Controllertyp, hier AVR Mega 32
$framesize = 32 'Stackanweisungen, die eigentlich nur bei größeren Programmen
$swstack = 32 'wirklich nötig werden
$hwstack = 32
$crystal = 16000000 'Die Frequenz des verwendeten Quarzes

$baud = 9600 'Die Baudrate für RS232 Ausgabe.
'Sie muss auch bei PC Terminalprogramm identisch sein

Config Portc.0 = Output 'Ein Pin wird aus Ausgang konfiguriert PC0 (also Pin0 von Port C)
Led Alias Portc.0
Config Pina.0 = Input 'Ein Pin (PA0) wird als Eingang definiert
Taster Alias Pina.0
Porta.0=1 'Interner Pullup Widerstand ein

do
if taster=0 then
Led=1 'Pin wird auf High, also 5V geschaltet
else
Led = 0 'Pin wird auf Low, also 0V geschaltet
endif
Waitms 100
loop
</pre>

==Siehe auch==
* [[Bascom - Erstes Programm in den AVR Controller übertragen]]
* [[RN-Control]]
* [[RNBFRA-Board]]
* [[Avr]]
* [[RN-Board FAQ-Seite]] mit wichtigen Einstiegstips
* [[Sourcevergleich]] - GCC und Bascom
* [[Bascom Inside]]

==Weblinks==
* [http://www.mcselec.com Niederländischer Hersteller MCSELEC]
* [http://www.robotikhardware.de Bezugsquelle in Deutschland u.a. Robotikhardware.de]
* [http://www.roboternetz.de/phpBB2/viewtopic.php?t=1511 Bauanleitungen zu Experimentier- und Roboterboards]
* [http://www.roboternetz.de/phpBB2/dload.php?action=file&file_id=169 RN-Timer Windows Programm zur Timer-Berechnung]

==Literatur==
* [[Buchvorstellungen|Programmieren der AVR RISC Mikrocontroller mit BASCOM-AVR; 2. Auflage]]
* [[Buchvorstellungen|Bascom–AVR, Autor M.Meissner - Beschreibung der Bascom IDE]]
* [[Buchvorstellungen|AVR-Microcontroller Lehrbuch – Ein tieferer Einstieg in Bascom und AT-MEGA8 und ähnliche AVR-Controller]]
* [[Buchvorstellungen|BASCOM-AVR Sprachbefehle - Ein umfangreiches Werk welches alle Befehle beschreibt ]]
* [[Buchvorstellungen|Mega16 Programmierung am Beispiel des RNBFRA-Boards]]

[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Software]]
[[Kategorie:Grundlagen]]
[[Kategorie:Robotikeinstieg]]
[[Kategorie:Praxis]]

RC5-Decoder für ATMega

2006-01-03T19:32:21Z

Nollsen: /* Autor */ Kategorie AVR

Dieser Code imlpementiert einen Interrupt-getriebenen RC5-Empfänger.

Auf eine Flanke an einem externen INT hin werden die nachfolgenden Pulslängen gemessen und in einer Struktur bereitgestellt, falls es sich um RC5-Code handelt und die Empfängeradresse übereinstimmt.

=Abgrenzung=

Nicht alle Fernbedienungen halten sich genau an die RC5-Spezifikation und haben oft einen mehr oder weniger starken Jitter auf dem Signal. In konstanten Zeitabständen auf den Port zu schauen und anhand des gelesenen Wertes das RC5-Signal aufzubauen, funktioniert daher nicht zuverlässig bei allen Fernbedienungen.

Der Ansatz, den diese Implementierung verfolgt, ist aufwändiger und ergibt ein längeres Programm, hat aber dafür nicht den beschriebenen Nachteil.

=Resourcen=

{| {{Blauetabelle}} valign="top"
|- bgcolor="#ccccff"
! |Resource
! |Verbrauch (mit <tt>-Os</tt>)
|-
|I/O
|Timer0, 1 Pin für extern INT
|-
|Interrupts
|Timer0 Overflow, 1 externer IRQ
|-
|Flash
| ~ 0x180
|- valign="top"
|SRAM
| statisch: 8<br/>Stack: 11
|- valign="top"
|Laufzeit,<br/>Erhöhung der IRQ-Latenz
| ?, aber statisch abschätzbar
|-
|externe Hardware
|IR-Empfänger wie TSOP17xx, TSOP18xx o.ä.
|}

=Schaltplan=
{| {{Blaueschmaltabelle}}
|[[Bild:Tsop-avr-connect.png|Anschluss TSOP17xx an AVR, R1 ca 10kΩ]]
|-
|<div align="center">IR-Empfänger vom Typ TSOP17xx an AVR<br>R1 ca 10 kΩ</div>
|}

=Interface=
<pre>
#define RC5_INT0 0
#define RC5_INT1 1

#define RC5_ALL 0xff

typedef struct
{
uint8_t code;
uint8_t addr;
volatile char flip;
} rc5_t;

extern rc5_t rc5;
extern void rc5_init (uint8_t addr);
</pre>

;<code>void rc5_init (uint8_t addr)</code>: Initialisiert die Hardware für RC5-Empfang. Akzeptiert wird Code, der an Adresse <code>addr</code> geschickt wird. Falls <code>addr = RC5_ALL</code> bzw Bit 7 von <code>addr</code> gesetzt ist, werden alle Adressen akzeptiert.
{{FarbigerRahmen|
Der beteiligte INT-Port wird ''nicht'' auf IN geschaltet und das I-Flag in <code>SREG</code> (Global Interrupt Enable/Disable-Flag) wird nicht verändert.
}}

;<code>extern rc5_t rc5</code>: In <code>rc5</code> wird der empfangene RC5-Code geliefert. Über dieses Objekt wird zudem der RC5-Empfang gesteuert. Wird ein Code mit der gewünschten Adresse ampfangen und ist <code>rc5.flip = -1</code>, dann wird der Code gespeichert und <code>rc5.flip</code> gesetzt wie es empfangen wurde.
Danach wird der Empfänger solange inaktiv, bis der Anwender wieder <code>rc5.flip</code> auf <code>-1</code> setzt.
:;<code>rc5.code</code>: der empfangene RC5-Code, falls <code>rc5.flip != -1</code>
:;<code>rc5.addr</code>: die Adresse, an die gesendet wurde, falls <code>rc5.flip != -1</code>
:;<code>rc5.flip</code>: das Flip-Bit
::;<code>rc5.flip = 0</code>: Code empfangen, RC5-Empfang inaktiv
::;<code>rc5.flip = 1</code>: dito
::;<code>rc5.flip = -1</code>: RC5-Empfang aktiv, wartet auf nächste Übertragung

{| {{Blauetabelle}}
|- bgcolor="#ccccff"
! |Define
! |default
! |Werte
! |Beschreibung
|-
|<code>RC5_INT</code>
|<code>RC5_INT0</code>
|<code>RC5_INT0</code>, <code>RC5_INT1</code>
|Code wird generiert für INT0 resp. INT1, zB gcc-Aufruf mit <code>-DRC5_INT=RC5_INT1</code> erzeugt Code für INT1
|-
|<code>RC5_PRESCALE</code>
|<code>1024</code>
|<code>64, 256, 1024</code>
|Legt den Prescaler für Timer0 fest. Standardeinstellung auf 1024, was zu F_CPU=16000000 passt. Für kleinere CPU-Frequenzen muss evtl ein kleinerer PRESCALE gewählt werden; das geht noch nicht automatisch.
|-
|<code>F_CPU</code>
|
|
|Gibt die CPU-Frequenz in Hz an
|}

=Seiteneffekte=

==SFRs==

Der Code verwendet folgende SFRs und ändert deren Inhalt in den ISRs:
: '''<code>MCUCR</code>''': MCU Control Reg
: '''<code>GICR</code>''': Global Interrupt Control Reg
: '''<code>TCNT0</code>''': Timer0 Counter Reg
: '''<code>TIMSK</code>''': Timer Interrupt Mask Reg

{{FarbigerRahmen|
Falls eines dieser SFRs verändert wird, nachdem RC5-Empfang aktiviert wurde, ''muss'' diese Änderung atomar erfolgen!

<pre>
#include <avr/io.h>
#include <avr/interrupt.h>

...
{
sreg = SREG;
cli();
TIMSK |= ...
SREG = sreg;
}
...
</pre>
}}

==Prescaler==

Timer0 verwendet den Prescaler. Ein Prescaler-Reset sollte aufgrund der langsamen Übertragung bei RC5 unkritisch sein.

=Code=

{| {{Blauetabelle}}
|'''ANSI-C'''
|Nein (C++ Kommentare, anonymous struct)
|-
|'''Dateien'''
| <code>rc5.h</code>, <code>rc5.c</code>
|-
|'''getestet für'''
| ATMega8-16 @ 16MHz, Vcc = 5V
|-
|'''Portierung'''
| ATMegaXX: sollte ohne Anpassung laufen<br>ATTiny, Classic: Anpassungen erforderlich
|-
|'''Comment-Style'''
| 
|}

==rc5.c==

<pre>
#include <avr/io.h>
#include <avr/signal.h>

#include "rc5.h"

#ifndef RC5_INT
#define RC5_INT RC5_INT0
#endif // RC5_INT

#ifndef RC5_PRESCALE
#define RC5_PRESCALE 1024
#endif // RC5_PRESCALE

//////////////////////////////////////////////////////////////////////////////

rc5_t rc5;

//////////////////////////////////////////////////////////////////////////////

#ifndef F_CPU
#error Please define F_CPU
#endif // !F_CPU

// µs for a whole bit of RC5 (first & second part)
#define RC5_BIT_US (64*27)

#define RC5_TICKS \
((uint8_t) ((uint32_t) (F_CPU / 1000 * RC5_BIT_US / 1000 / RC5_PRESCALE)))

#define RC5_DELTA \
(RC5_TICKS / 6)

typedef union
{
uint16_t w;
uint8_t b[2];

struct
{
unsigned code:6;
unsigned addr:5;
unsigned flip:1;
unsigned agc:4;
} __attribute__ ((packed));

} code_t;

static code_t code;
static uint8_t rc5_addr;

// Number of Bits received so far
// Number of Interrupts occured so far;
static uint8_t nbits;
static uint8_t nint;

//////////////////////////////////////////////////////////////////////////////

void
rc5_init (uint8_t addr)
{
nint = 0;
nbits = 0;
rc5.flip = -1;

rc5_addr = addr;

#if (RC5_PRESCALE==1024)
TCCR0 = (1 << CS02) | (1 << CS00);
#elif (RC5_PRESCALE==256)
TCCR0 = (1 << CS02);
#elif (RC5_PRESCALE==64)
TCCR0 = (1 << CS01) | (1 << CS00);
#else
#error This RC5_PRESCALE is not supported
#endif // RC5_PRESCALE

// INTx on falling edge
// clear pending INTx
// enable INTx interrupt
#if (RC5_INT == RC5_INT0)
MCUCR |= (1 << ISC01);
MCUCR &= ~ (1 << ISC00);
GIFR = (1 << INTF0);
GICR |= (1 << INT0);
#elif (RC5_INT == RC5_INT1)
MCUCR |= (1 << ISC11);
MCUCR &= ~ (1 << ISC10);
GIFR = (1 << INTF1);
GICR |= (1 << INT1);
#else
#error please define RC5_INT
#endif // RC5_INT
}

//////////////////////////////////////////////////////////////////////////////

SIGNAL (SIG_OVERFLOW0)
{
TIMSK &= ~(1 << TOIE0);

uint8_t _nbits = nbits;
code_t _code = code;

if (26 == _nbits)
{
_nbits++;
_code.w <<= 1;
}

if (27 == _nbits
&& 3 == _code.agc
&& 0 > rc5.flip)
{
uint8_t _rc5_code;
uint8_t _rc5_addr;
// we do the bit manipulation stuff by hand, because of code size
_rc5_code = _code.b[0] & 0x3f; // 0b00111111 : #0..#5
_code.w <<= 2;
_rc5_addr = _code.b[1] & 0x1f; // 0b00011111 : #6..#10

if (rc5_addr & 0x80
|| rc5_addr == _rc5_addr)
{
rc5.code = _rc5_code;
rc5.addr = _rc5_addr;
char flip = 0;
if (_code.b[1] & 0x20) // 0b00100000 : #11
flip = 1;
rc5.flip = flip;
}
}

nint = 0;
nbits = 0;

// INTx on falling edge
// clear pending INTx
// enable INTx interrupt
#if (RC5_INT == RC5_INT0)
MCUCR |= (1 << ISC01);
MCUCR &= ~ (1 << ISC00);
GIFR = (1 << INTF0);
GICR |= (1 << INT0);
#elif (RC5_INT == RC5_INT1)
MCUCR |= (1 << ISC11);
MCUCR &= ~ (1 << ISC10);
GIFR = (1 << INTF1);
GICR |= (1 << INT1);
#endif
}

//////////////////////////////////////////////////////////////////////////////

#if (RC5_INT == RC5_INT0)
SIGNAL (SIG_INTERRUPT0)
#elif (RC5_INT == RC5_INT1)
SIGNAL (SIG_INTERRUPT1)
#endif // RC5_INT
{
code_t _code = code;
uint8_t _nint = nint;

if (0 == _nint)
{
// INTx on both edges
// clear pending INTx
#if (RC5_INT == RC5_INT0)
MCUCR &= ~ (1 << ISC01);
MCUCR |= (1 << ISC00);
GIFR = (1 << INTF0);
#elif (RC5_INT == RC5_INT1)
MCUCR &= ~ (1 << ISC11);
MCUCR |= (1 << ISC10);
GIFR = (1 << INTF1);
#endif // RC5_INT

TCNT0 = 0;
TIFR = (1 << TOV0);
TIMSK |= (1 << TOIE0);
_code.w = 0;
}
else
{
uint8_t tcnt0 = TCNT0;

TCNT0 = 0;

// Number of bits of the just elapsed period;
uint8_t n = 1;
// Bits received so far
uint8_t _nbits = nbits;

// is TCNT0 close to RC5_TICKS or RC5_TICKS/2 ?
if (tcnt0 > RC5_TICKS + RC5_DELTA)
goto invalid;
else if (tcnt0 < RC5_TICKS/2 - RC5_DELTA)
goto invalid;
else if (tcnt0 > RC5_TICKS - RC5_DELTA)
n = 2;
else if (tcnt0 > RC5_TICKS/2 + RC5_DELTA)
goto invalid;

// store the just received 1 or 2 bits
do
{
_nbits++;
if (_nbits & 1)
{
_code.w <<= 1;
_code.b[0] |= _nint & 1;
}
}
while (--n);

if (0)
{
invalid:

// disable INTx, run into Overflow0
#if (RC5_INT == RC5_INT0)
GICR &= ~(1 << INT0);
#elif (RC5_INT == RC5_INT1)
GICR &= ~(1 << INT1);
#endif // RC5_INT

_nbits = 0;
}

nbits = _nbits;
}

code = _code;
nint = 1+_nint;
}
</pre>

==rc5.h==
<pre>
#ifndef _RC5_H_
#define _RC5_H_

#include <inttypes.h>

#define RC5_INT0 0
#define RC5_INT1 1

#define RC5_ALL 0xff

typedef struct
{
uint8_t code;
uint8_t addr;
volatile char flip;
} rc5_t;

extern rc5_t rc5;
extern void rc5_init (uint8_t addr);

#endif /* _RC5_H_ */
</pre>

=Beispiele=

==Initialisierung==

<pre>
#include <avr/io.h>
#include <avr/interrupt.h>

#include "rc5.h"

...
// der ensprechende INT-Port muss INPUT sein
// RC5 initialisieren, alle Adressen zulassen
rc5_init (RC5_ALL);

// Interrupts zulassen
sei();
...
</pre>

==Anwendung==

<pre>
#include <avr/io.h>
#include <avr/interrupt.h>

#include "rc5.h"

...
// FIXME: eigentlich sollte es nicht nötig sein, das atomar zu machen
// Code atomar machen
uint8_t sreg = SREG;
cli();
// Gibt's was Neues?
if (-1 == rc5.flip)
{
// Nein, dann
// atomaren Block beenden
SREG = sreg;
// ...und zurück (oder sonst was machen)
return;
}
// Ja, dann code merken, und evtl. rc5.addr, falls man die nicht sowieso kennt
uint8_t code = rc5.code;
// und auf nächstes Zeichen warten
rc5.flip = -1;

// atomaren Block beenden
SREG = sreg;
// code (evtl. addr) auswerten
...
</pre>

=WebLinks=
* [http://www.atmel.com/dyn/resources/prod_documents/DOC1473.PDF AVR410 (Application Note): ''RC5 IR Remote Control Receiver'', pdf (en)]

=Autor=

--[[Benutzer:SprinterSB|SprinterSB]] 18:17, 7. Dez 2005 (CET)
[[Kategorie:AVR]]
[[Kategorie:Software]]
[[Kategorie:Praxis]]
[[Kategorie:Quellcode C]]

TWI

2006-01-03T19:32:19Z

Nollsen: /* Siehe auch */ Kategorie AVR

= Two-wire Serial Interface =

Bezeichnung von [[Atmel|Atmel]] für den auf vielen [[AVR|AVR]]'s vorhandenen [[I2C|I<sup>2</sup>C]].

In diesem Artikel soll nur auf Besonderheiten der [[Atmel]] [[Microcontroller]] eingegangen werden, Einzeilheiten zu [[I2C|I<sup>2</sup>C]] finden sich in den entsprechenden Artikeln.

= Merkmale =

* Master- und Slavemodus
* Multimaster
* 7-Bit Adressierung (als Master möglicherweise auch 10-Bit Adressierung)
* Übertragungsrate von bis zu 400kBit/s

= TWI verwenden =
Um TWI mit dem [[AVR]] verwenden zu können sind einige Einstellungen nötig, die hier, in Abhängigkeit der Anwendung, aufgezeigt werden.

== Übertragungsarten ==
Bei TWI gibt es diese Übertragungsarten
* Master Transmitter (nur senden)
* Master Receiver (senden und empfangen)
* Slave Transmitter (auf abruf senden)
* Slave Receiver (nur empfangen)
Abhängig von der Anwendung, kann der [[AVR]] alle Arten der Übertragung im gleichen Programm ausführen.

== Master ==
Ist der AVR Master, bestimmt er was und wie schnell es auf dem [[I2C|I<sup>2</sup>C]]-Bus zugeht. (Ausnahme: [[Clock_Stretching]] )

Zur Bestimmung der Bus-Geschwindigkeit ist der ''Bit Rate Generator'' zuständig.

=== Bit Rate Generator ===
Zur Übertragung gibt es die Bitraten ''Standard'', mit bis zu 100kBit/s, und ''FastMode'', mit bis zu 400kBit/s.
Der Master muss immer den Takt erzeugen, der bei bedarf auf der Leitung SCL angelegt wird.
Der SCL-Takt ist beim AVR abhängig von der CPU-Frequenz, deshalb ist es von Vorteil (im gegensatz zu RS232), wenn man Frequenzen mit geraden Werten verwendet, zB. 8.0 MHz, da sich der Wert besser teilen lässt um auf 100kHz bzw. 400kHz zu kommen.

Im TWI-Modul des AVR gibt es zwei stellen, an denen man die Teilung der Frequenz einstellen kann.
* die ''Prescaler Bits'' (TWPS), diese 2 Bits befinden sich im ''TWI Status Register'' (TWSR)
* für die genauere Einstellung das ''TWI Bit Rate Register'' (TWBR)

'''Formel zur Berechnung der SCL-Frequenz:'''
<div align="center">
<math>\mathrm{SCL{-}Frequenz = \frac{CPU{-}Frequenz}{16\ +\ 2\ ( TWBR )\ 4 ^ { TWPS } } }</math>
</div>

Da ein AVR zur Zeit max. mit 20MHz getaktet werden kann, ist es nicht nötig den Prescaler zu benutzen, bzw. er wird auf den Teiler 1 gestellt, was keiner Teilung entspricht. Mit diesem Teiler können alle CPU-Frequenzen und TWI-Takte abgedeckt werden.

'''Mögliche Prescaler Werte:'''
<div align="center">
{| {{Blauetabelle}}
|'''BitWert'''
|'''Teiler'''
|-
|00
|1
|-
|01
|4
|-
|10
|16
|-
|11
|64
|}
</div>
Die Werte von TWBR gehen von theoretisch 0 bis 255. Laut [[Atmel]] soll der Wert aber mind. 10 Betragen, da es sonst zu Problemen bei der Übertragung kommen kann.

'''Beispiel Berechnung'''

Es soll eine SCL-Frequenz von 100kHz erzeugt werden, die CPU-Frequenz beträgt 8.0MHz, der Teiler (Prescaler) ist, wie oben erwähnt, auf 1 (TWPS = 0).

Laut der Formel ergibt das dann:
<pre>100kHz = 8.0MHz / (16 + 2 * x * 4^0 ) / 1 fällt weg
100kHz = 8.0MHz / (16 + 2 * x ) / *(16 + 2 * x )
100kHz * (16 + 2 * x ) = 8000kHz / kürzen / : 100
16 + 2 * x = 80 / -16
2 * x = 64 / :2
x = 32
</pre>
'''Ergebnis:''' Der Wert für TWBR muss 32 sein, damit die SCL-Frequenz 100kHz, bei 8.0MHz CPU-Frequenz, ergibt.

'''Es Ergibt sich somit Folgende Formel zum Berechnen von TWBR:'''
<div align="center">
<math>\mathrm{TWBR = \frac{ \frac {CPU{-}Frequenz}{SCL{-}Frequenz} - 16}{2}}</math>
</div>

Kommt ein Wert kleiner 10 heraus, sollte eine höhere CPU-Frequenz gewählt werden. Wird eine krumme CPU-Frequenz verwendet was kein Ganzzahliges Ergebnis zur folge hat, kann man mit der 1. Formel überprüfen ob der Wert auf- oder Abgerundet wird. Auf der sicheren Seite ist man, wenn der Wert aufgerundet wird, das entspricht einer grösseren Teilung, also eine geringfügig kleinere Bitrate und liegt deshalb im Standard.

= Quellen =
Atmel Datenblätter

= Siehe auch =
* [[I2C|I<sup>2</sup>C]]
* [[RS232]]
* [[RS485]]
* [[RN-Slave ID Übersicht]]

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

WinAVR

2006-01-03T19:32:15Z

Nollsen: /* Weblinks */ Kategorie AVR

WinAVR ist Paket für die C-Programmierung von [[AVR]]-Controllern. genauer gesagt ist es eine Portierung des beliebten Open Source Compilers [[avr-gcc]].
Das Paket beinhaltet neben dem GCC-Compiler (Cross Compiler) noch Linker, Editor, Standard Libarys und viele kleinere Tools. Die Installation erfolgt jedoch unter Windows bequem über ein einziges SETUP-Programm. Der Vorteil dieses Paketes ist also die einfache Installation.

Vorhandene Tools in WinAVR:

* [[Avr-gcc]] - der C Compiler
* avr-libc - Libary mit Standard Funktionen
* Mfile - Tool zum Erstellen von Makefiles
* AVR Insight - Debugger
* Programmers Notepad - Editor mit Syntax Highlightning
* avrdude - Übertragungssoftware für Programmcode (verschiedene ISP Programmer)

==Siehe auch==
* [[C-Tutorial]]
* [[Avr-gcc]]
* [[Sourcevergleich]]
* [[Avr]]
* [[Atmel]]
* [[Compiler]]

==Weblinks==
* [http://sourceforge.net/projects/winavr/ aktuellste Version über sourceforge.net]
[[Kategorie:AVR]]
[[Kategorie:Microcontroller]]
[[Kategorie:Robotikeinstieg]]

Avr-gcc

2006-01-03T19:29:08Z

Nollsen: /* Autor */

Die GNU Compiler Collection (GCC) unterstützt das Zielsystem (Target) [[Avr|AVR]] für die Sprachen C und C++. GCC ist ein sehr leistungsfähiger [[Compiler]], und er kann als die wichtigste freie Software überhaupt bezeichnet werden. Immerhin sind das freie [[Betriebssystem]] <tt>Linux</tt> und viele andere Programme  auch gcc und die Toolchains selbst  mit gcc generiert.


=How to Read=

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

Der Artikel ist ein Handbuch zu <tt>avr-gcc</tt>. Er bespricht zum Beispiel, wie man <tt>avr-gcc</tt> anwendet und
Besonderheiten von <tt>avr-gcc</tt>-C,
die nicht zum Sprachumfang von C gehören.
Dazu zählen die Definition von Interrupt Service Routinen (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 (Blinky)|Blinky]]",
das nur eine [[LED]] blinkt und zeigt,
wie ein kleines Projekt mit <tt>avr-gcc</tt> compiliert werden kann.

=Benutzer-Schnittstelle=

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

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

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

=Allgemeine Charakteristika von avr-gcc=

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

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

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

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

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

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

=Ablauf der Codegenerierung=

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

==Übersichts-Grafik==

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

==Schritte der Codegenerierung==

Ohne die Angabe spezieller Optionen werden die Zwischenformate nur als temporäre Dateien angelegt und nach Beenden des gcc-Laufs wieder gelöscht. Dadurch fällt die Aufgliederung in Unterschritte nicht auf. In diesem Falle müssen Assembler und Linker/Locator auch nicht extra aufgerufen werden, sondern die Aufrufe erfolgen durch gcc. Ausnahme ist <tt>avr-objcopy</tt>, welches immer aufgerufen werden muss, wenn man z.B. eine HEX-Datei haben möchte.

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

#define MAKRONAME ERSATZTEXT

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

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

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

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

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

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

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

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

==Allgemeine Optionen für GCC==
; <tt>--help</tt>: Anzeige der wichtigsten Optionen
; <tt>--help -v</tt>: Überschüttet einen mit Optionen
; <tt>--target-help</tt>: Anzeige der wichtigsten maschinenspezifischen Optionen
; <tt>-O0</tt>: keine Optimierung
; <tt>-O1</tt>: Optimierung
; <tt>-Os</tt>: optimiert für Code-Größe
; <tt>-O2</tt>: stärkere Optimierung für bessere Laufzeit
; <tt>-g</tt>: erzeugt Debug-Informationen
; <tt>-c</tt>: (pre)compilert und assembliert nur bis zum Objekt (*.o), kein [[Linker|link]]-Lauf
; <tt>-S</tt>: (pre)compilert nur und erzeugt [[Assembler]]-Ausgabe (*.s)
; <tt>-E</tt>: nur Precompilat (*.i) erzeugen, kein Compilieren, kein Assemblieren, kein Linken
; <tt>-o</tt> <filename>: legt den Name der Ausgabedatei fest
; <tt>-v</tt>: zeigt Versionsinformationen an und ist geschwätzig (verbose): Anzeige der aufgerufenen tools
; <tt>-I</tt><path>: Angabe eines weiteren Include-Pfads, in dem Dateien mit <tt>#include <...></tt> gesucht werden
; <tt>-E -dM </tt> <filename>:Anzeige aller Defines
; <tt>-D</tt><name>:Definiert [[Makro]] <tt><name></tt>
; <tt>-D</tt><name>=<wert>:Definiert Makro <tt><name></tt> zu <tt><wert></tt>
; <tt>-U</tt><name>:Undefiniert Makro <tt><name></tt>
; <tt>-save-temps</tt>:Temporäre Dateien (*.i, *.s) werden nicht gelöscht. Teilweise fehlerhaft zusammen mit <tt>-c</tt>

; <tt>-Wa,</tt><options>: übergibt Komma-getrennte Liste <tt><options></tt> an den Assembler (<tt>avr-as</tt>)
; <tt>-Wp,</tt><options>: übergibt Komma-getrennte Liste <tt><options></tt> an den Preprozessor
; <tt>-Wl,</tt><options>: übergibt Komma-getrennte Liste <tt><options></tt> an den Linker (<tt>avr-ld</tt>)
; <tt>-Wall</tt>: gibt mehr Warnungen, aber immer noch nicht alle
; <tt>-pedantic</tt>: geht bedonders pedantisch mit Code um
; <tt>-ansi</tt>: bricht mit einer Fehlermeldung ab, wenn kein ANSI-C verwendet wurde
; <tt>-ffreestanding</tt>: Das erzeugte Programm läuft nicht in einer Umgebung wie einer Shell. Der Prototyp von <tt>main</tt> ist
:<tt>
void main (void);
</tt>

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

Zwar gibt es für alle AVR-Derivate die <tt>avr/io.h</tt>, aber die AVR-Familien unterscheiden sich in ihrer Hardware; z.B. darin, wie 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

=Builtin Defines=

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

==GCC==
;<tt>__GNUC__</tt>: X wenn GCC-Version X.Y.Z
;<tt>__GNUC_MINOR__</tt>: Y wenn GCC-Version X.Y.Z
;<tt>__GNUC_PATCHLEVEL__</tt>: Z wenn GCC-Version X.Y.Z
;<tt>__VERSION__</tt>: "X.Y.Z" wenn GCC-Version X.Y.Z
;<tt>__GXX_ABI_VERSION</tt>: Version der ABI (Application Binary Interface)
;<tt>__OPTIMIZE__</tt>: Optimierung ist aktiviert
;<tt>__NO_INLINE__</tt>: Ohne Schalter <tt>-finline</tt> resp. <tt>-finline-all-functions</tt> etc.
;<tt>__ASSEMBLER__</tt>: GCC betrachtet die Eingabe als Assembler-Code und compiliert nicht. Weiterleitung an den Assembler.

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

Siehe auch: [[Avr-gcc#Maschinenspezifische_Optionen_f.C3.BCr_avr-gcc|Maschinenspezifische Optionen]]

=Sections=

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

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

{| {{Blauetabelle}}
|- bgcolor="#ccccff"
! |Section
! |Ablage
! |Betrifft
! |Beschreibung
|-
|<tt>.text</tt>
|Flash
|Code
|normaler Programm-Code
|-
|<tt>.data</tt>
|SRAM
|Daten
|wird vom Startup-Code initialisiert, u.a. aus <tt>.progmem</tt>
|-
|<tt>.bss</tt>
|SRAM
|Daten
|wird vom Startup-Code zu 0 initialisiert
|-
|colspan="4" bgcolor="#bbbbff"|
|-
|<tt>.progmem</tt>
|Flash
|Daten
|wird vom Startup-Code nach <tt>.data</tt> kopiert
|-
|<tt>.eeprom</tt>
|EEPROM
|Daten
|Daten im EEPROM
|-
|<tt>.noinit</tt>
|SRAM
|Daten
|wird nicht initialisiert
|-
|colspan="4" bgcolor="#bbbbff"|
|-
|<tt>.init''n''</tt>
|Flash
|Code
|wird vor <tt>main</tt> ausgeführt, ''n'' = 0...9
|-
|<tt>.fini''n''</tt>
|Flash
|Code
|wird nach <tt>main</tt> ausgeführt, ''n'' = 9...0
|-
|<tt>.vectors</tt>
|Flash
|Code
|Vektor-Tabelle: Tabelle mit Sprüngen zur jeweiligen ISR
|-
|<tt>.bootloader</tt>
|Flash
|Code
|für den Bootloader
|}

Der Anfang einer Section kann auch dem Linker mitgegeben werden, etwa wenn wie üblich <tt>avr-gcc</tt> als Treiber für den Linker verwendet wird:
avr-gcc ... -Wl,--section-start=.eeprom=0x810001
Damit beginnt Section <tt>.eeprom</tt> nicht an der (virtuellen) Adresse <tt>0x810000</tt>,
sondern ein Byte später.
Manche AVRs haben einen Silicon-Bug, der bei Verwendung der EEPROM-Adresse 0 zu Fehlern führt.
Mit der obigen Linker-Option wird diese Adresse nicht mehr verwendet.

=Attribute=

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

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

==Nützliche Attribute von GCC==

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

==Attribute von avr-gcc==

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

'''Beispiele:'''

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

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

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

=Dynamische Speicherallokierung=

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

Eine resourcen-schonendere Möglichkeit, zur Laufzeit an Speicher zu kommen,
bietet <tt>__builtin_alloca</tt>.
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.
Den so erhaltenen Speicher braucht man nicht freizugeben, das geschieht beim Verlassen der Funktion
in deren Epilog.

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

{{FarbigerRahmen|
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!

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

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

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

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

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

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

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

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

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

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

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

{{FarbigerRahmen|
Zu beachten ist, daß dieser Zugriff nicht atomar erfolgt. Das Lesen/Schreiben mehrbytiger Werte muss vom Compiler in mehrere Byte-Zugriffe zerlegt werden. Zwischen diesen Zugriffen kann ein Interrupt auftreten, was zu fehlerhaften Resultaten führen kann. Entsprechende Codestücke müssen daher atomar gehalten werden!
}}

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

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

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

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

==Interrupts==

Um zu kennzeichnen, daß es sich bei einer Funktion um eine Interrupt Sevice Routine (ISR) handelt, gibt es spezielle Attribute. Diese brauchen nicht explizit hingeschrieben zu werden, ebensowenig wie die genaue Nummer des Interrupt Requests (IRQ). Dafür gibt es die Includes und die Makros:
<pre>
#include <avr/io.h>
#include <avr/signal.h>

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

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

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

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

;<tt>SIGNAL</tt>: Mit Ausführung einer ISR deaktiviert die AVR-Hardware die Interrupts, so daß die ISR nicht durch andere Interrupt-Anforderungen unterbrochen wird. Beim Verlassen der ISR werden Interrupts wieder aktiviert.
;<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.

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

Nachschlagen kann man den Name 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>

===default Interrupt===

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

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

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

Wenn man komplett eigenes Zeug machen will, dann macht man eine nackte Funktion,
die z.B. eine Meldung ausgibt, in einer Endlosschleife landet, oder über den [[Watchdog]]
einen richtigen Reset auslöst. Falls <tt>__vector_default</tt> zurückkehren soll,
dann ist darauf zu achten, daß man dies mit <tt>reti</tt> (return from interrupt) tut
und evtl. verwendete Register und den Status (<tt>SREG</tt>) sichert:
<pre>
void __attribute__ ((naked))
__vector_default (void)
{
__asm__ __volatile (
"; mach was" "\n\t"
"; mach was" "\n\t"
"reti"
);
}
</pre>

===ISR mit eigenem Prolog/Epilog===
Genauso implementiert man auch eine kleine ISR mit minimalem Overhead.
Mit <tt>naked</tt> befreit man die Routine vom Standard-Prolog/Epilog und
kümmert sich selbst darum:
<pre>
#include <avr/io.h>

void __attribute__ ((naked))
SIG_OVERFLOW0 (void)
{
/* Port B.6 = 0 */
__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>

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

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

while (*str++)
len++;

return len;
}
</pre>

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

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

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

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

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

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

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

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

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

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

==Reset auslösen==
Falls ein Reset per Software ausgelöst werden soll, denn 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 RESET. So kann man z.B. via [[UART]] ein RESET-Kommando schicken. Allerdings lässt sich der Watchdog nur minimal auf 15ms einstellen:
<pre>
#include <avr/wdt.h>
#include <avr/interrupt.h>
...
cli(); // Interrupts global abschalten
wdt_enable (WDTO_15MS); // Watchdog aufziehen auf 15ms
while (1); // warten, bis er zubeisst...
</pre>

==Zufall==
"Echte" Zufallszahlen zu generieren ist leider nicht möglich, hierzu muss man externe Hardware wie einen [[Rauschgenerator]] verwenden. Funktionen wie <tt>rand</tt> und <tt>random</tt> basieren auf algebraischen Verfahren, die eine gute Verteilung der gelieferten Werte haben. Werden diese Funktionen mit dem selben Startwert (seed) initialisiert, liefern sie auch immer die gleiche Folge. In diesem Sinne sind die Werte nicht zufällig sondern nur scheinbar zufällig und "wüst umherhüpfend".

Um einen zufälligen Startwert zu erhalten, kann man den uninitialisierten Inhalt des SRAM verwenden, das nach dem power-up keinen definierten Zustand hat.

===Startwert (seed) besorgen===
Am einfachsten geht dies, indem man eine Variable in die Sektion <tt>.noinit</tt> lokatiert und den Wert liest:
<tt>
unsigned long seed __attribute__ ((section (".noinit")));
</tt>

Etwas bessere Resultate erhält man, wenn man den ganzen Inhalt des nicht verwendeten SRAMs zur Bildung der seed heranzieht. Das Symbol <tt>__heap_start</tt> wird übrigens im standard Linker-Script definiert, <tt>RAMEND</tt> ist ein Makro aus <tt>ioxxxx.h</tt>:

Das Beispiel interpretiert den SRAM-Inhalt als <tt>unsigned short</tt> Werte und berechnet die seed, indem die einzelnen Werte mit exor "überlagert" werden.

<pre>
#include <avr/io.h>

unsigned short get_seed()
{
unsigned short seed = 0;
unsigned short *p = (unsigned short*) (RAMEND+1);
extern unsigned short __heap_start;

while (p >= &__heap_start + 1)
seed ^= * (--p);

return seed;
}
</pre>

=== Pseudozufall in der avr-libc===
In der <tt>avr-libc</tt> finden sich Funktionen, um Pseudo-Zufallszahlen zu erhalten bzw. um Startwerte für die Algorithmen zu setzen:

#include <stdlib.h>

Prototypen und Defines:
<pre>
#define RAND MAX 0x7FFF

int rand (void);
void srand (unsigned int seed);

long random (void);
void srandom (unsigned long seed);
</pre>

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

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

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

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

=Includes=

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

==Standard==

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

==AVR-spezifisch==

Die AVR-spezifischen Includes finden sich wie gesagt im Unterverzeichnis <tt>avr</tt>.
Die meisten dort befindlichen Header wird man nie direkt durch Angabe im C-File erhalten,
sondern durch Angabe von
#include <avr/io.h>
Dadurch werden z.B. genau der I/O-Header eingebunden, der zum AVR-Modell passt, also
<tt>avr/iom8.h</tt> für ATMega8,
<tt>avr/iotn2313</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>'
und für ATTiny '<tt>avr/iotn*.h</tt>'.
<pre>
avr/boot.h Bootloader Support
avr/crc16.h Prüfsumme CRC16
avr/delay.h Verzögerungsschleife - loops for small accurate delays
avr/eeprom.h EEPROM-Routinen
avr/ina90.h Kompatibilität mit IAR-AVR-Compiler
avr/interrupt.h sei(), cli(), ...
avr/io.h --> inttypes.h, io*.h
avr/io*.h SFRs, SIG_****, SPM_PAGESIZE, RAMEND, XRAMEND, E2END, FLASHEND
avr/parity.h Parität
avr/pgmspace.h Zugriff aufs Flash: Byte lesen, PROGMEM, prog_char, prog_uint8_t, ...
avr/portpins.h Makros für Port-Pins
avr/signal.h Makros SIGNAL() und INTERRUPT(), ...
avr/sleep.h Power-Safe
avr/twi.h I2C
avr/wdt.h Watchdog
</pre>

=Optimierungen, Tipps & Tricks=

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

Um das Ergebnis zu beurteilen, hilft ein Blick ins Listfile.
Siehe dazu auch die Abschnitte
"[[Hallo Welt für AVR (Blinky)#Listfile erstellen|Listfile erstellen]]"
und
"[[Hallo Welt für AVR (Blinky)#Die Größe ermitteln|Die Größe ermitteln]]"
im [[Hallo Welt für AVR (Blinky)|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 ist das Compiler-Builtin <tt>__builtin_alloca</tt> eine effiziente Alternative, siehe auch im Abschnitt "[[avr-gcc#Dynamische Speicherallokierung|Dynamische Speicherallokierung]]".

==Konstante Strings ins Flash==
Konstante Strings wie sie zu Ausgabezwechen 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 die im Flash liegen zuzugreifen, tragen die Suffix <tt>_P</tt>, wie z.B. <tt>strcmp_P</tt> mit dem Prototyp
extern int *strcmp_P (char *, const prog_char *)
Die Implementierungen befinden sich in der <tt>avr-libc</tt>.

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

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

==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==

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

Hier ein Beispiel, daß Division mit Rest für <tt>unsigned short</tt> verwendet, um eine 16-Bit-Zahl in Dezimaldarstellung zu wandeln:
<pre>
// Struktur definieren und Funktion bekannt machen
typedef struct
{
unsigned short quot;
unsigned short rem;
} udiv_t;

extern udiv_t __udivmodhi4 (unsigned short, unsigned short);

#define udiv __udivmodhi4

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

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

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

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

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

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

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

return s;
}
</pre>

Falls man eine Division und/oder Rest für 8-Bit braucht, dann geht für <tt>unsigned</tt>:
<pre>
typedef struct
{
unsigned char quot;
unsigned char rem;
} udiv8_t;

extern udiv8_t __udivmodqi4 (unsigned char, unsigned char);

#define udiv8 __udivmodqi4
</pre>

===Division durch Multiplikation===
===Vermeiden von float und double===
=Dateien (WinAVR)=

WinAVR bringt wesentlich mehr mit als nur <tt>avr-gcc</tt>:
* Binutils (Assembler (<tt>avr-as</tt>), Linker (<tt>avr-ld</tt>), Tools (<tt>avr-size</tt>, <tt>avr-objdump</tt>, <tt>avr-objcopy</tt>, <tt>avr-nm</tt>, ...))
* Debugger (<tt>avr-gdb</tt> mit Oberfläche <tt>insight</tt>)
* Bibliothek <tt>avr-libc</tt> inclusive Dokumentation
* Progger <tt>avrdude</tt>
* Progger <tt>uisp</tt>
* AVR-Simlator (simulavr),
* Programmers Notepad (kleiner Editor)
* Demo-Projekte
* viele Linux-Tools wie <tt>make</tt>, <tt>grep</tt>, <tt>sed</tt>, <tt>tar</tt>, etc.
* ...

'''Verzeichnisbaum''' (Auszug):

<pre>
. avr-gcc Installations-Verzeichnis
./avr/include Standard Includes
./avr/include/avr Includes AVR-spezifisch
./avr/lib Startup-Code, Libs (avr2)
./avr/lib/avr3 " (avr3)
./avr/lib/avr4 " (avr4)
./avr/lib/avr5 " (avr5)
./avr/lib/ldscripts Linker-Skripte
./bin Programme (avr-gcc.exe, giveio.sys, ...
./doc Doku (HTML + pdf)
./doc/avr-libc avr-libc
./doc/avrdude-xxx avrdude
./doc/simulavr-xxx simulavr
./doc/uisp-xxx uisp
./examples Beispiel-Projekte
./examples/demo PWM mit AT90S2313
./examples/twitest I2C mit ATMega
./info info pages
./man man pages
./mfile mfile
./pn Programmers Notepad
./utils/bin bzip2, diff, gawk, grep, make, sed, tar, ...
</pre>

=Fallstricke und häufige Fehler=

==Tippfehler==

Tippfehler können immer passieren. Besonders fies ist es, wenn der Tippfehler nicht zu einer Warnung oder zu einer Fehlermeldung führt, weil der entstandene Code korrekter C-Code ist.

===Ein <tt>;</tt> zu viel===
Ein reflexartig eingetippter oder nach Ändeungen stehen gebliebener <tt>;</tt> hat schon so manches
Programm ausgeknockt:
if (a == 0);
{
/* mach was */
}
Wenn <tt>a == 0</tt> ist, dann wird <tt>;</tt> ausgeführt (also im Endeffekt garnichts). Danach kommt der Block, der im <tt>if</tt> stehen sollte. Der wird immer ausgeführt, denn er gehört nicht mehr zum <tt>if</tt>.

===Zuweisung statt Vergleich===
if (a = 0)
{
/* mach was */
}
Zuerst wird <tt>a = 0</tt> gesetzt und dann überprüft, ob die <tt>if</tt>-Bedingung erfullt ist. Der Wert ist aber immer <tt>0</tt>, was ''nicht erfüllt'' bedeutet. Der nachfolgende Block wird nie betreten.

Abhilfe schafft, sich angewohnen zu schreiben
if (0 == a)
Wenn man dann eine Zuweisung eintippt, gibt's einen Fehler.

===Signal/Interrupt-Name vertippt oder Leerzeichen zu viel===

SIGNAL (SIG_OVEFRLOW0)
{
/* mach was */
}
Nicht alle Compiler-Versionen meckern da. Der ISR-Code wird nicht in die Interrupt-Tabelle eingetragen. Kommt es zum Interrupt, dann landet man in RESET.

==Nicht-atomarer Code==
Verwendet man in einem Programm IRQs (Interrupts) und ändert in der ISR (Service Routine) ein Datum (Variable, SFR, ...), dann wird diese Änderung möglicherweise überschrieben, wenn die IRQ zu einem ungünstigen Zeitpunkt auftritt.
Ein Beispiel, das zeigt, was passieren kann, findet sich im Abschnitt "[[avr-gcc#Zugriff auf einzelne Bits|Zugriff auf einzelne Bits]]". Ein weiteres Beispiel ist das Lesen, Schreiben oder Testen einer mehrbytigen Variable:
<pre>
int volatile i;
...
if (0 == i)
</pre>
Weil <tt>i</tt> länger als 1 Byte ist, kann es nicht in einem Befehl gelesen werden;
daher kann während des Lesens eine IRQ auftreten, in deren ISR der Wert von <tt>i</tt>
verändert wird. Der obige Code könnte etwa so assembliert werden:
<pre>
; i wird vom SRAM in das Registerpaar r24:r25 geladen
; low-Teil laden
lds r24,i
; high-Teil laden
; wenn hier eine IRQ zuschlägt, in der i verändert wird, ist der Registerinhalt korrupt
lds r25,(i)+1
or r24,r25
brne ...
</pre>
Natürlich können auch komplexere Datenstrukturen von diesem Phänomen betroffen sein.
Besonders unangenehm an dieser Klasse von Fehlern ist, daß sie nur sporadisch auftauchen
und man sie daher selbst mit einem guten Debugger sehr schlecht orten kann, da die zugehörige
Codestelle fast immer korrekt abgearbeitet wird.

Entweder man macht den ganzen betroffenen Block ununterbrechbar (atomar):
<pre>
#include <avr/io.h>
#include <avr/interrupt.h>
...
unsigned char sreg = SREG;

cli();
if (0 == i)
{
i = 1;
SREG = sreg;
}
else
{
SREG = sreg;
return;
}
...
</pre>
oder je nach Programmstruktur sichert man den Wert, z.B. in eine lokale Variable.

==Mangelnde C-Kenntnis==

===Warnung ignoriert===

::"''Wieso soll das Probleme machen? Das ist doch nur eine Warnung!''"

Warnungen zur Compile-Zeit werden gerne zu Fehlern zur Laufzeit. Letztere sind deutlich schwerer zu finden, als angewarnten Code zu korrigieren.
<pre>
void foo (long*);

void bar (int *p)
{
foo (p+1);
// Was soll das sein?!
// ((long*) p) + 1 oder
// (long*) (p + 1)
}
</pre>

<pre>
> avr-gcc -c -o prog.o prog.c

prog.c: In function `bar':
prog.c:5: warning: passing arg 1 of `foo' from incompatible pointer type
</pre>

===Array-Index===

Informatiker am Bahnhof:
:''"0, 1, 2, ... Wo ist mein dritter Koffer?!"''
Gleiches gilt für Arrays:
#define NUM 10;
int a[NUM]; // für die N Werte a[0] ... a[N-1]
Ein Zugriff auf <tt>a[N]</tt> greift igrdendwo hin.
Wahlweise liest man Schrott oder überschreibt andere Daten, die in der Nähe liegen, und
plötzlich seltsame Werte enthalten.

===Bitweise vs. Logische Operatoren===

Die Operatoren AND, OR und NOT gibt es in C in zwei Ausprägungen
;bitweise: Die Operatoren <tt>^</tt>, <tt>|</tt>, <tt>&</tt>, <tt>~</tt>, <tt>|=</tt>, <tt>^=</tt>, <tt>&=</tt>, <tt>|=</tt> operieren bitweise. Der entsprechende Operator wird also auf alle Bits des Wertes parallel angewandt und das Ergebnis für ein Bit ist unabhängig vom Inhalt der anderen Bits.
;logisch: Die Operatoren <tt>||</tt>, <tt>&&</tt>, <tt>!</tt>, <tt>&&=</tt>, <tt>||=</tt> operieren auf dem ganzen (int) Wert und berücksichtigen nur, ob der Wert 0 (false) oder ungleich 0 (true) ist.
Dementsprechend liefert <tt>&&</tt> i.d.R. ein anderes Ergebnis als <tt>&</tt>:
if (a && b) // erfüllt, wenn a!=0 und b!=0
if (a & b) // erfüllt, wenn in a und b an der gleichen Stelle ein Bit gesetzt ist
Ein Verwechseln bzw. unkorrektes Einsetzen der Operatoren gibt also ein falsches Programm.

===TRUE ist nicht 1===

Da C die Begriffe TRUE und FALSE eigentlich nicht kennt, wurde schon öfter beobachtet, daß folgendes definiert wurde:
#define TRUE 1
#define FALSE 0
solange man damit nur Schalter setzt und abfragt, ist dagegen nichts zu sagen.
a = TRUE; b = FALSE;
if ( (a == TRUE) && (b == FALSE)) {.."this is true"..}
wenn man aber dann schreibt
if ( (a & b) == TRUE) {.."this is true"..}
kann man einen herbe Enttäuschung erleben. Man müßte für ein richtiges Ergebnis schreiben
if ( (a & b) != FALSE) {.."this is true"..}
Damit ist aber eine gute Lesbarkeit endgültig dahin.

Besser sind Definition wie
#define FALSE (0!=0)
#define TRUE (0==0)
denn damit gilt einerseits, daß für alle boolschen Werte einschliesslich dieser Konstanten der
Zusammenhang <tt>x = !!x</tt> besteht.
Mit der allerersten Definition hat man das unerwünschte Ergebnis <tt>TRUE != !FALSE</tt>.
Andererseits kann man direkt gegen diese Konstanden vergleichen:
a = (x < y);
...
if (a == TRUE) // oder die 'klassische' Variante: if (a)

===Ein , anstatt . in Konstante===

In C sowie im angloamerikanischen Sprachraum werden Dezimalbrüche mit einem <tt>.</tt> (Punkt) geschrieben und nicht wie im Deutschen mit einem <tt>,</tt> (Komma):
float pi;
pi = 3,14; // *AUTSCH* soll wohl heissen 3.14
Die zweite Zeile besteht aus zwei durch ein Komma getrennten Anweisungen, so daß das ganze
etwa gleichbedeutend ist mit
float pi;
pi = 3;
14;
Jedenfalls ist es korrekter C-Code!
Die <tt>14;</tt> ist ein Ausdruck, der nicht weiter gebraucht wird und daher wegfällt, da
er im Gegensatz zu einer void-Funktion keine Wirkung hat.
Man rechnet also mit dem Wert 3 für <math>\pi</math>.

Das falsche Komma hat auch schon so manchen ebay-Freak aufs Kreuz gelegt...

===Führende 0 in Konstanten===

In C kennzeichnet eine führende 0 bei einer Zahlenkonstante,
daß die Zahl oktal dargestellt ist. Somit ist 010 nicht gleich 10.
if (a == 030) // ist a gleich 24?

==Warteschleife==

Siehe dazu auch [[Warteschleife]].

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

=Siehe auch=
*[[Avr]]
*[[Atmel]]
*[[Compiler]]
*[[Sourcevergleich]]
* [[WinAVR]]
*[[Hallo Welt für AVR (Blinky)]] - ein erstes Beispiel für avr-gcc
*[[:Kategorie:Quellcode_C|C-Codebeispiele]]

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

=ToDo=
* inline asm
* optimizing

=Autor=

--[[Benutzer:SprinterSB|SprinterSB]] 11:27, 7. Dez 2005 (CET)
[[Kategorie:AVR]]
[[Kategorie:Grundlagen]]
[[Kategorie:Microcontroller]]
[[Kategorie:Praxis]]
[[Kategorie:Software]]

Avr

2006-01-03T19:28:40Z

Nollsen: /* Weblinks */

Hersteller der AVR-Controllerserie ist [[Atmel]].
[[Bild:AtmelController.jpg|thumb|Beispiel eines Atmel Controllers]]
Es gibt eine ganze Serie von AVR-Controllern. Sie alle werden ähnlich programmiert bieten jedoch unterschiedliche Features (I/O Leitungem, Timer, [[Pwm]]-Ports usw.)
Es gibt inzwischen Entwicklungssysteme in den Sprachen Basic, C, Pascal und Assembler für diese Controller. AVR steht angeblich für Advanced Virtual RISC (in einem Paper von Alf Egin Bogen und Vegard Wollan)

* 8 Bit Architektur ist für Hochsprachen (C) optimiert
* Harvard-Architektur (getrennter Befehls- und Datenspeicher)
* 32 Register, kein Akkumulator, 3 Pointerregister
* In-System progammierbar - Das bedeutet der Controller kann sehr einfach über ein Programmierkabel (oft ISP-Kabel genannt ) das mit dem PC verbunden wird programmiert werden, auch dann wenn sich dieser in einer Schaltung befindet
* JTAG (Debugerinterface)
* AVR Typen (AT90, ATtiny, ATmega)
* Viele Entwicklungsboards erhältlich, z.B. das Roboternetzboard [[RN-Control]]

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

* [[AT90S2313]]
* [[Atmel Controller Mega8]]
* [[Atmel Controller Mega48 Mega88 Mega168]]
* [[Atmel Controller Mega16 und Mega32]]
* [[Atmel Controller Mega128]] - [[SMD]]-Chip

----

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

{| {{Blauetabelle}}
|'''PA 0 – 7'''
|Port A - Ein 8 Bit breiter, bi-direktionaler I/O Port. Jeder Pin des Ports kann individuell als Eingang oder Ausgang konfiguriert werden.
|-
|'''PB 0 – 7'''
|Port B - Ein 8 Bit breiter, bi-direktionaler I/O Port. Jeder Pin des Ports kann individuell als Eingang oder Ausgang konfiguriert werden.
|-
|'''PC 0 – 7'''
|Port C - Ein 8 Bit breiter, bi-direktionaler I/O Port. Jeder Pin des Ports kann individuell als Eingang oder Ausgang konfiguriert werden.
|-
|'''PD 0 – 7'''
|Port D - Ein 8 Bit breiter, bi-direktionaler I/O Port. Jeder Pin des Ports kann individuell als Eingang oder Ausgang konfiguriert werden.
|-
|'''XCK'''
|Externe Takt für UART. Wird nur in Sonderfällen für Baudrate benötigt.
UART ("Universal Asynchronous Receiver and Transmitter"). Das ist die serielle Schnittstelle, die zur Datenübertragung zwischen Mikrocontroller und PC genutzt wird. Zur Übertragung werden zwei Pins am Controller benötigt: TXD und RXD. Über TXD ("Transmit Data") werden Daten gesendet, RXD ("Receive Data") dient zum Empfang.
|-
|'''T0'''
|Timer Eingang. Timer kann gestartet, gestoppt oder getaktet werden
|-
|'''T1'''
|Timer Eingang. Timer kann gestartet, gestoppt oder getaktet werden
|-
|'''AIN0'''
|Erster Eingang des Analog Komperators.
Mit AIN0 und AIN1 kann man zwei Spannungen miteinander vergleichen. Wenn die Spannung an AIN0 höher als bei AIN1 ist, liefert der Komparator "High", wenn umgekehrt ein "Low".
|-
|'''AIN1'''
|Zweiter Teil des Analog Komperators
Mit AIN0 und AIN1 kann man zwei Spannungen miteinander vergleichen. Wenn die Spannung an AIN0 höher als bei AIN1 ist, liefert der Komparator "High", wenn umgekehrt ein "Low".
|-
|'''OC0'''
|PWM bzw. Output Compare Ausgang des Timers 0
|-
|'''SS'''
|SPI-Interface – wird beneötigt um den richtigen Slave am Bus zu wählen
|-
|'''MOSI'''
|SPI-Interface – Datenausgang (bei Slave Eingang)
|-
|'''MISO'''
|SPI-Interface – Dateneingang (bei Slave Ausgang)
|-
|'''SCK'''
|SPI-Interface – Bustakt vom Controller
|-
|'''RESET'''
|Rücksetz Eingang. Ein log. 0 – Pegel an diesem Pin für die Dauer von mindestens zwei Zyklen des Systemtaktes bei aktivem Oszillator setzt den Controller zurück
|-
|'''VCC'''
|Betriebsspannung 5 V
(2,7 Volt bis 6 V bei 8 Mhz, die nächsten AVRs sollen ab 1,8 Volt funktionieren )
|-
|'''GND'''
|Masse
|-
|'''XTAL1'''
|Eingang des internen Oszillators zur Erzeugung des Systemtaktes bzw. Eingang für ein externes Taktsignal, wenn der interne Oszillator nicht verwendet werden soll
|-
|'''XTAL2'''
|Ausgang des integrierten Oszillators zur Erzeugung des Systemtaktes
|-
|'''RXD'''
|Serielle Schnittstelle Eingang TTL-Pegel
|-
|'''TXD'''
|Serielle Schnittstelle Ausgang TTL-Pegel
|-
|'''INT0'''
|Externe Interrupt
|-
|'''INT1'''
|Externe Interrupt
|-
|'''INT2'''
|Externer Interrupt 2
|-
|'''OC1A'''
|Ausgang für die Compare-Funktion des integrierten Zeitgeber- / Zählerbausteines
Der erste PWM Ausgang des Timers1. Er wird oft zum Regeln der Bot-Motogeschwindigkeit benutzt.
|-
|'''OC1B'''
|Ausgang für die Compare-Funktion des integrierten Zeitgeber- / Zählerbausteines
Der zweite PWM Ausgang des Timers1. Er wird oft zum Regeln der Bot-Motogeschwindigkeit benutzt.
|-
|'''ICP1'''
|Eingang für die Capture-Funktion des integrierten Zeitgebers / Zählerbausteines
|-
|'''ADC0 bis ADC7'''
|Eingänge des Analag nach Digital (AD) Wandlers. Spannungen können hier gemessen werden.
|-
|'''AREF'''
|Referenzspannung für Analog-Digitalwandler (wird meist auf 5 V gesetzt)
|-
|'''GND'''
|Masse
|-
|'''AVCC'''
|Analog Digital Wandler (siehe Beschaltungsskizze)
Die Betriebsspannung für den AD Wandler. Die Pins AVCC, AGND und AREF sollten immer beschaltet werden, da es sonst es passieren kann, dass Port A nicht richtig funktioniert, selbst wenn man den AD Wandler nicht benutzt
|-
|'''TOSC1'''
|TOSC1 und 2 sind Eingänge für den Asyncronen Modus von Timer2. Sie sind vorgesehen für den Anschluss eines externen Uhrenquarzes ( 32.768 kHz ). Damit lässen sich zum Beispiel sehr genaue 1 Sekunden Impulse für eine Uhr generien...
|-
|'''TOSC2'''
|TOSC1 und 2 sind Eingänge für den Asyncronen Modus von Timer2. Sie sind vorgesehen für den Anschluss eines externen Uhrenquarzes ( 32.768 kHz ). Damit lässen sich zum Beispiel sehr genaue 1 Sekunden Impulse für eine Uhr generien...
|-
|'''TDI'''
|JTAG-Debug Interface - Über dieses Interface kann man den AVR programmieren und debuggen. Die Schnittstelle ist ähnlich wie die SPI Schnittstelle und hat getrennte Dateneingangs- und Datenausgangsleitungen sowie eine Taktleitung. TDI ist die Dateneingangsleitung
|-
|'''TDO'''
|JTAG-Debug Interface - TDO ist die Datenausgangsleitung des JTAG Interface
|-
|'''TMS'''
|JTAG-Debug Interface
|-
|'''TCK'''
|JTAG-Debug Interface
|-
|'''SDA'''
|[[I2C]]-Schnittstelle (Bus aus 2 Leitungen) Datenleitung
|-
|'''SCL'''
|I2C-Schnittstelle (Bus aus 2 Leitungen) Clockleitung
|-
|'''OC2'''
|[[Pwm]] bzw. Output Compare Ausgang des Timers2
|-
|'''PEN'''
|Programming Enable - Diesen Pin gibt es nur beim Mega128/64 u.ä. Wird dieser Pin beim Power-On Reset nach Masse gezogen geht der Controller in den ISP Programmiermodus. Man kann ihn also alternativ zu Reset verwenden. In der Regel verwendet man aber die Reset Leitung und PEN sollte man direkt mit VCC verbinden.
|}
----

== Timer der AVRs ==

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

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

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

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

[[Bild:AbstrakterZaehlvorgang.png]]

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

[[Bild:Prescaler.png]]

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

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

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

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

[[Bild:NormalerModus_1.png]]

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

[[Bild:NormalerModus_1_Vorladen.png]]

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

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

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

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

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

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

Zusammenfassend ein Beispielprogramm:

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

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

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

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

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

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

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

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

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

[[Bild:NormalerModus_CompareMatch.png]]

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

Wiederum zusammenfassend ein Beispielprogramm:

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

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

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

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

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

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

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

[[Bild:NormalerModus_CompareMatch.png]]

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

=== Registerübersicht ===

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

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

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

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

----

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

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

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

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

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

''Autoren des Artikels: Frank, Luma''

==Siehe auch==
* [[Atmel]]
* [[AVR-Einstieg leicht gemacht]]
* [[Avr-gcc|avr-gcc]] - Leistungsfähiger AVR-Port des freien Compilers GCC
* [[AVR_Assembler_Einf%C3%BChrung|AVR Assembler Einführung (AvrStudio)]]
* [[AVR-ISP Programmierkabel]] - Bauanleitung für die AVR Controller Programmierkabel
* [[RN-Control]] - Eines der beliebtestet AVR-Boards im Roboternetz
* [[RNBFRA-Board]] - Größeres Board mit zwei Atmel Controllern
* [[Bascom]] - Sehr gutes Basic-Entwicklungssystem
* [[Bascom - Erstes Programm in den AVR Controller übertragen]]
* [[On Chip Debugging]]
* [[Bootloader]]
* [[Timer]]

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

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