Mikrocontroller.net - Benutzerbeiträge [de]

FAQ

2013-12-11T16:14:14Z

Cmf: Rechtschreibfehler

Ein Verzeichnis von im Forum oft gestellten und immer wieder beantworteten Fragen und den zugehörigen Antworten:

=Wie kann ich Zahlen auf [[LCD]]/[[UART]] ausgeben?=

Aber die Bibliothek, die du benutzt, stellt nur eine Funktion zur Verfügung, mit der man einen String ausgeben kann... Was tun?

In den folgenden Beispielen wird eine selbstgeschriebene Funktion zur Stringausgabe auf LCD - die Funktion lcd_string() - aus dem [[AVR-GCC-Tutorial/LCD-Ansteuerung|LCD-Teil des AVR-GCC-Tutorials]] verwendet:

<syntaxhighlight lang="c">
lcd_string( "Hallo Welt" ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Um also eine Zahl (numerische Konstante oder Variableninhalt) auszugeben, muss von dieser Zahl zunächst ihre String-Repräsentation ermittelt werden. Hier geht es aber nur darum, zu zeigen wie man diese String Repräsenation erzeugen kann. Was man dann mit diesem String weiter macht, ob das dann eine LCD-Ausgabe oder eine UART-Übertragung oder das Abspeichern auf SD-Karte oder ... ist, spielt eine untergeordnete Rolle.

Es gibt mehrere Möglichkeiten, sich die Stringrepräsentation zu erzeugen:

===itoa() (utoa(), ltoa(), ultoa(), ftoa() )===

<b>itoa()</b> ist keine C-Standardfunktion (wohl aber ihre Umkehrung <b>atoi()</b> ). Auf manchen Compilern heisst diese Funktion dann folgerichtig <b>_itoa()</b>, wobei der führende _ eben anzeigt, dass es sich um eine Erweiterung des C-Standards handelt. Bei [[WinAVR]] ist itoa() Bestandteil der mitgelieferten Library avr-libc, in der Library [http://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html''stdlib.h''].

<syntaxhighlight lang="c">
#include <stdlib.h>
char Buffer[20];
int i = 25;

itoa( i, Buffer, 10 );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

<b>itoa( i, Buffer, 10 );</b> - Die Zahl i wird nach ASCII gewandelt und die String Repräsentierung davon wird in Buffer abgelegt. Die Basis, in der diese Wandlung erfolgt, ist das 10-er System. Wird das dritte Argument von 10 in zb. 2 oder auch 16 abgewandelt, erhält man die binäre oder eben eine hexadezimale Repräsentierung des Wertes. Auch wenn 10, 2 und 16 die häufigsten Angaben an dieser Stelle sind, kann itoa aber grundsätzlich in jedes beliebige Zahlensystem wandlen.

Wichtig ist, darauf zu achten, dass das Array <i>Buffer</i> groß genug dimensioniert wird, um alle Zeichen der Textrepräsentation der Zahl aufzunehmen - inklusive der 0, die den String abschließt, sowie ein mögliches Vorzeichen.

Anzumerken bleibt weiter, dass es normalerweise für alle Datentypen entsprechende Umwandlungsfunktionen gibt, wenn es sie für einen Datentyp gibt. Die Namensgebung lehnt sich an das Schema an: ''Kürzel_für_den_Datentyp to a''. Eine Funktion die einen unsigned int wandelt, heißt dann utoa (oder _utoa), Floating Point heißt dann ftoa (oder _ftoa), etc.

===sprintf()===

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "%d", i );
lcd_string( Buffer ); // ggf. auch lcd_out() o.ä. in anderen Libraries
</syntaxhighlight>

Diese Methode funktioniert auch bei long oder float Werten. Unbedingt beachtet werden muss allerdings, dass die Typkennzeichnungen im sog. Format-String (hier "%d") mit den tatsächlichen Typen der auszugebenden Werten übereinstimmt. Und dass der Buffer, der den Text aufnimmt, auch groß genug dimensioniert wird. Dabei sollte die 0, die den String terminiert, nicht vergessen werden.

Mit sprintf() hat man dieselben Möglichkeiten zur Formatierung wie bei <b>printf()</b> (siehe unten). Insbesondere gibt es natürlich die Möglichkeit die Zahl gleich in einen umgebenden Text einzubetten bzw. Formatierungen anzugeben:

<syntaxhighlight lang="c">
char Buffer[20];
int i = 25;

sprintf( Buffer, "Anzahl: %d Stueck", i );
lcd_out( Buffer );
</syntaxhighlight>

Der "Haken" an der mächtigen Funktion sprintf() ist, daß sie auch bei minimalisierter Konfiguration verhältnismäßig viel Programmspeicher (Flash-ROM) belegt und relativ viel Prozesszeit benötigt. Daher sollte man sprintf() nur verwenden, wenn kein Speicher- und Prozesszeitmangel besteht. Sonst sollte itoa() oder eine eigene, auf die Bedürfnisse optimierte Implementierung auf jeden Fall vorgezogen werden. Der große Vorteil von sprintf liegt darin, dass man über sehr mächtige Formatiermöglichkeiten verfügt, mit der man die Ausgabe einfach steuern und an seine Bedürfnisse anpassen kann. Dinge die man mit einer Funktion wie itoa alle selbst 'händisch' erledigen muss.

====Formatierungen mit printf====

Für jedes auszugebende Argument muss es im Formatstring einen entsprechenden Formatbezeichner geben. Der Aufbau eines Formatbezeichners ist immer

%[Modifizierer][Feldbreite][.Präzision]Typ

(Die in eckigen Klammern [ ] angegebenen Elemente können auch weggelassen werden, wenn man sie nicht benötigt. Im einfachsten Fall benötigt man also nur das % und den Buchstaben zur Typ-Kennung.)

<b>Typ</b> ist dabei eine Kennung, der mit dem Datentyp des jeweiligen auszugebenden Argumentes übereinstimmen muss. Einige oft benutzte Kennungen, ohne Anspruch auf Vollständigkeit, sind:
<b>c</b> char
<b>d</b> int
<b>f</b> float, double
<b>ld</b> long
<b>u</b> unsigned int
<b>lu</b> unsigned long
<b>p</b> pointer
<b>s</b> string
<b>x</b> ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl
<b>X</b> ein int wird ausgegeben, die Ausgabe erfolgt
aber als Hexadezimalzahl, wobei Grossbuchstaben verwendet werden

Der''Modifizierer'' bestimmt, wie und womit nicht benutzte Felder des Ausgabefeldes gefüllt werden sollen, wie die Ausrichtung innerhalb des Feldes erfolgen soll und ob ein Vorzeichen auch dann ausgegeben werden soll wenn die auszugebende Zahl positiv ist. Wird kein Modifizierer angegeben, so werden nicht benutzte Felder mit einem Leerzeichen gefüllt, positive Vorzeichen unterdrückt und die Ausgabe im Feld rechts ausgerichtet.

<b>+</b> Vorzeichen wird immer ausgegeben
<b>-</b> Die Ausgabe wird im Ausgabefeld linksbündig ausgerichtet
<b>0</b> anstelle von Leerzeichen werden führende 0-en ausgegeben

Die ''Feldbreite'' gibt die Breite des Ausgabefeldes an, in die die Ausgabe durchgeführt werden soll. Reicht die angegebene Feldbreite nicht aus, so vergrößert printf diese Breite eigenmächtig. Die Feldbreite muß nicht angegeben werden. In diesem Fall bestimmt printf selbst die Feldbreite, so dass die Ausgabe darin Platz findet. Mit der Feldbreite hat man eine simple Möglichkeit dafür zu sorgen, dass der erzeugte String immer eine konstante Länge hat, selbst wenn die auszugebende Zahl diese Länge gar nicht benötigen würde (wichtig zb. bei Tabellen, damit die Einerstellen der Tabelleneinträge auch sauber untereinander stehen, auch dann wenn die Zahlen sich in unterschiedlichen Wertebereichen bewegen).

Die ''Präzision'' kommt nur bei float oder double Zahlen zum Einsatz. Sie legt fest, wieviele Positionen der kompletten Feldbreite für die Ausgabe von Nachkommastellen reserviert werden sollen. Auch sie muss wiederrum nicht angegeben werden und printf benutzt in so einem Fall Standardvorgaben.

===== Beispiele =====
;<tt>"%d"</tt>: Ausgabe eines Integer
;<tt>"%5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite
;<tt>"%05d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite, wobei das Feld links mit führenden Nullen auf 5 Zeichen aufgefüllt wird
;<tt>"%-5d"</tt>: Ausgabe eines Integer in einem Feld mit 5 Zeichen Breite. Die Zahl wird linksbündig in das Feld gestellt.
;<tt>"%6.3f"</tt>: Ausgabe eines float (oder double). Die Ausgabe erfolgt in einem Feld mit 6 Zeichen Breite, wobei 3 Nachkommastellen ausgegeben werden. Achtung: In der Feldbreite ist auch ein eventuelles Vorzeichen sowie der Dezimalpunkt enthalten. Bei einer Feldbreite von 6 Zeichen und 3 Nachkommastellen, bleiben bei einer positiven Zahl daher nur 2 Positionen für den Vorkommaanteil, bei negativen sogar nur 1 Stelle (6 - 3 Nachkommastellen - 1 Dezimalpunkt - 1 Vorzeichen = 1)

===Eigene Umwandlungsfunktionen===

Möchte man <b>itoa()</b> nicht benutzen oder hat es gar auf seinem System nicht zur Verfügung, dann ist es auch nicht schwer, sich selbst eine Funktion dafür zu schreiben:

<syntaxhighlight lang="c">
void ItoA( int z, char* Buffer )
{
int i = 0;
int j;
char tmp;
unsigned u; // In u bearbeiten wir den Absolutbetrag von z.

// ist die Zahl negativ?
// gleich mal ein - hinterlassen und die Zahl positiv machen
if( z < 0 ) {
Buffer[0] = '-';
Buffer++;
// -INT_MIN ist idR. größer als INT_MAX und nicht mehr
// als int darstellbar! Man muss daher bei der Bildung
// des Absolutbetrages aufpassen.
u = ( (unsigned)-(z+1) ) + 1;
}
else {
u = (unsigned)z;
}
// die einzelnen Stellen der Zahl berechnen
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );

// den String in sich spiegeln
for( j = 0; j < i / 2; ++j ) {
tmp = Buffer[j];
Buffer[j] = Buffer[i-j-1];
Buffer[i-j-1] = tmp;
}
Buffer[i] = '\0';
}
</syntaxhighlight>

Das Grundprinzip ist einfach:<br>
Die Ermittlung der einzelnen Stellen erfolgt in der zentralen Schleife

<syntaxhighlight lang="c">
do {
Buffer[i++] = '0' + u % 10;
u /= 10;
} while( u > 0 );
</syntaxhighlight>

durch fortgesetzte Division durch 10 und Restbildung.

8392

8392 % 10 -> <b>2</b>
8392 / 10 -> 839

839 % 10 -> <b>9</b>
839 / 10 -> 83

83 % 10 -> <b>3</b>
83 / 10 -> 8

8 % 10 -> <b>8</b>
8 / 10 -> 0

Nur leider erhält man dadurch die einzelnen Ziffern der Zahl in umgekehrter Reihenfolge im String ('2' '9' '3' '8' anstelle von '8' '3' '9' '2'). Dies ist aber kein Problem, die nachfolgende Schleife

<syntaxhighlight lang="c">
for( j = 0; j < i / 2; ++j ) {
tmp = Buffer[j];
Buffer[j] = Buffer[i-j-1];
Buffer[i-j-1] = tmp;
}
</syntaxhighlight>

spiegelt den String in sich, sodass danach der String eine korrekte Repräsentation der ursprünglichen Zahl darstellt. Der Funktionsteil vor der 'Zerlegeschleife' behandelt den Sonderfall daß die Zahl negativ ist. Negative Zahlen werden behandelt indem im Endergebnis ein '-' vermerkt wird und danach die Zahl positiv gemacht wird.

Siehe auch:
* Forenbeitrag [http://www.mikrocontroller.net/topic/67405#541885 Integer-Zahl in String mit bestimmter Zeichenlänge]
* Forenbeitrag [http://www.mikrocontroller.net/topic/84005#704736 (Resourcenschonend) Wert einer Variable am LCD ausgeben] von Niels Hüsken
* Forenbeitrag [http://www.mikrocontroller.net/topic/121526?goto=new#new Formatierte Zahlenausgabe in C] von Peter Dannegger
* [[Festkommaarithmetik]]

=Datentypen in Operationen=
Ein häufiges Problem betrifft die Auswertung von Ausdrücken. Konkret die Frage nach den beteiligten Datentypen.
zb
<syntaxhighlight lang="c">
double i;
int j, k;

i = j / k;
</syntaxhighlight>
Die Frage lautet dann: Warum erhalte ich keine Kommastellen, ich weise doch das Ergebnis einem double zu?

Dazu ist zu sagen, dass C nicht so funktioniert. Die Tatsache dass i eine double Variable ist, ist für die Auswahl der Operation, welche die Division durchführt, völlig irrelevant. C orientiert sich ausschliesslich an den
Datentypen der beteiligten Operanden, um zu entscheiden ob die Division als Integer- oder als Gleitkommadivision durchzuführen ist. Und da sowohl j als auch k ein Integer sind, wird die Division als Integerdivision durchgeführt
unabhängig davon, was mit dem Ergebnis weiter passiert. Erst nach der Division wird das Ergebnis in einen double überführt, um es an i zuweisen zu können. Zu diesem Zeitpunkt gibt es aber keine Kommastellen mehr, eine Integerdivision erzeugt keine. Und damit tauchen klarerweise auch im Ergebnis keine auf.

Aus genau diesem Grund ist zb das Ergebnis von
<syntaxhighlight lang="c">
double i;
i = 5 / 8;
</syntaxhighlight>
eine glatte 0 und nicht 0.625. Die Division 5 / 8 wird als Integer Division gemacht und liefert als solche keine Nachkommastellen. Wird das Ergebnis der Division in einen double umgewandelt, um es an i zuweisen zu können, ist das Kind schon in den Brunnen gefallen: Die Nachkommastellen sind schon längst weg bzw. waren nie vorhanden.

Will man den Compiler dazu zwingen, die Division als Gleitkommadivision durchzuführen, so muss man daher dafür sorgen, dass mindestens einer der beteiligten Operanden ein double Wert ist. Dann bleibt dem Compiler nichts anderes übrig, als auch den zweiten Operanden ebenfalls zu einem double zu machen und die Operation als Gleitkommaoperation durchzuführen.

<syntaxhighlight lang="c">
double i;
i = 5.0 / 8.0;

i = (double)j / k;
</syntaxhighlight>

Generell implementiert der Compiler eine Operation immer im 'höchsten' Datentyp, der in dieser Operation vorkommenden Operanden. Operanden in einem 'niedrigeren' Datentyp werden automatisch immer in diesen 'höchsten' Datentyp umgewandelt, zumindest aber int. Die Reihung orientiert sich dabei an der Regel: Ein 'höherer' Datentyp kann alle Werte eines 'niedrigeren' Datentyps aufnehmen.

int
unsigned int
long
unsigned long
long long
unsigned long long
double

float kommt in dieser Tabelle gar nicht vor, da Gleitkommaoperationen grundsätzlich immer als double-Operationen durchgeführt werden. Wohl kann es aber sein, dass double und float dieselbe Anzahl an Bits benutzen. Damit reduziert sich eine double Operation effektiv auf eine float Operation. (Anmerkung: mit dem C99-Standard hat sich dieses geändert. Dort gibt es dann auch echte float Operationen)

Hat man also in einer Operation 2 Operanden der Datentypen int und long, so wird der int implizit zu einem long gemacht und die Operation als long Operation durchgeführt. Das Ergebnis hat dann den Datentyp long.

==Welche Datentypen haben Konstanten==

Auch Zahlenkonstante besitzen einen Datentyp, der selbstverständlich vom Compiler bei der Auswahl der Operation berücksichtigt wird. Hier gilt die Regel: Benutzt wird der Datentyp, der die Zahl gerade noch aufnehmen kann. Eine Zahlenkonstante 5 hat daher den Datentyp int. Die Zahl 32767 passt gerade noch in einen int, und hat daher den Datentyp int. 32768 ist für einen int bereits zu groß und hat daher den Datentyp long. 5.0 ist hingegem immer eine double-Konstante. Der Dezimalpunkt erzwingt dieses.

Eine kleine Feinheit gibt es noch zu beachten. Konstanten in dezimaler Schreibweise haben immer einen signed Datentyp, während Konstanten in hexadezimaler bzw. oktaler Schreibweise je nach Wert einen signed oder einen unsigned Datentyp haben können.

Möchte man einer Konstanten einen bestimmten Datentyp aufzwingen, so gibt es dazu 2 (ein halb) Möglichkeiten:
* Entweder man castet die Konstante in den gewünschten Datentyp
<syntaxhighlight lang="c">
(long)5
</syntaxhighlight>
* oder man benutzt die in C dafür vorgesehene Schreibweise, indem man der Konstanten einen Suffix anhängt, der den gewünschten Datentyp beschreibt
<syntaxhighlight lang="c">
5L
</syntaxhighlight>
Beides ergibt eine dezimale 5, die vom Datentyp long ist.

* eine Zahl in mit einem Dezimalkomma
<syntaxhighlight lang="c">
5.0
</syntaxhighlight>
ist immer eine double Zahl. Es sei denn sie hat explizit einen Suffix
<syntaxhighlight lang="c">
5.0F
</syntaxhighlight>
dann hat man es mit einer float Zahl zu tun.

Die gültigen Suffixe für Zahlen sind U, L, UL und F:

* U wie unsigned; dabei wird zuerst int angenommen. Es erfolgt eine automatische Ausweitung auf long, wenn die Zahl den Wertebereich eines unsigned int überschreitet.
* L wie long; die Zahl selbst kann int oder double sein.
* UL wie unsigned long. Eigentlich eine Zusammensetzung aus U und L
* F wie float.

Präprozessordefinitionen besitzen keine eigene Datentypen, da sie eine reine Textersetzungen durchführen. Deren Inhalte können aber ggf. zu Werten aufgelöst werden, die datentypbehaftet sind.

=Aktivieren der Floating Point Version von sprintf bei WinAVR bzw AVR-Studio=
[[Bild:AVR_Studio_float1.gif|thumb|right|300px|Project → Configuration Options → Libraries → Available Link Objects]]
[[Bild:AVR_Studio_float2.gif|thumb|right|300px|Custom Options → Custom Compilation Options → Linker Options]]
Beim WinAVR/AVR-Studio wird standardmässig eine Version der printf-Bibliothek verwendet, die keine Floatingpoint-Verarbeitung unterstützt. Die meisten Programme benötigen keine Floatingpoint-Unterstützung, so dass dadurch wertvoller Programmspeicherplatz gespart werden kann.

Benutzt man allerdings eine printf-Variante für die Ausgabe von Floatingpoint-Zahlen, so erscheint an Stelle der korrekt formatierten Zahl lediglich ein '?'. Dies ist ein Indiz dafür, dass die Floatingpoint-Verarbeitung im Projekt aktiviert werden muss.

Um die Floatingpoint-Verarbeitung zu aktivieren, geht man im '''AVR Studio 4''' wie folgt vor:
* Menüpunkt: ''Project → Configuration Options''
* Im sich öffnenden Dialog wird in der linken Navigationsleiste der Eintrag ''Libraries'' ausgewählt.
* Unter ''Available Link Objects'' werden Bibliotheken angeboten. Für die Aktivierung der Floatingpoint-Unterstützung sind 2 interessant<ref><tt>libc.a</tt> sollte nicht zu den Bibliotheken hinzugefügt werden, da sie automatisch eingebunden wird. Etwas Hintergrundinformationen gibt es in [http://www.mikrocontroller.net/topic/173630 diesem Thread.]
</ref>:
** <tt>libprintf_flt.a</tt>
** <tt>libm.a</tt>
* Beide Bibliotheken werden durch Aktivieren und einen Druck auf ''Add Library → '' in die rechte Spalte übernommen.
* Danach wählt man in der Navigationsleiste den Eintrag ''Custom Options''.
* Unter ''Custom Compilation Options'' wird ''Linker Options'' ausgewählt und in das Textfeld rechts/unten folgender Text eingetragen:
-Wl,-u,vfprintf
* Ein Druck auf ''Add'' befördert die Zeile in das Listenfeld darüber, welches Optionen für den Linker enthält.
* Mit ''OK'' wird die Konfiguration abgeschlossen.

Bei '''AVR Studio 5''' trägt man die Optionen an anderen Stellen ein ([http://www.mikrocontroller.net/topic/221583#2219612 Beitrag von Hal Smith]):
*''Project Properties → Toolchain → AVR/GNU C-Linker → Libraries''<br/>In ''Libraries'' <tt>(-WI, -I), libprintf_flt.a libm.a</tt> eintragen.
* ''Project Properties → Toolchain → AVR/GNU C-Linker → Miscellaneous''<br/>In ''Other Linker Flags'' <tt>-Wl,-u,vfprintf</tt> eintragen.
{{Absatz}}

= Wie funktioniert String-Verarbeitung in C? =
: → Siehe: ''[[String-Verarbeitung in C]]''

= struct Strukturen =

: → Siehe: ''[[Strukturen in C]]''

= Funktionszeiger =

: → Siehe: ''[[Funktionszeiger in C]]''

= Header File - wie geht das =

Ein Header File ist im Grunde nichts anderes als eine Sammlung aller Informationen, die ein 'Aussenstehender' benötigt, um die in einem C-File gesammlten Funktionen benutzen zu können.

Trotzdem gibt es immer wieder Schwierigkeiten, wie sich die Sache mit Header Files und/oder #include verhält und wie man eine derartige Lösung aufbauen kann.

Gegeben sei ein System bestehend aus 3 Funktionen
* main()
* functionA()
* functionB()
und einigen globalen Variablen. Für dieses System soll eine Aufteilung erfolgen, so dass funtionA samt seinen zugehörigen globalen Variablen in einer eigenen C-Datei residiert (FileA.c), functionB in einem eigenen File residiert (FileB.c) und main() als Hautpfunktion seine eigens C-File (Main.c) darstellt und jeweils die entsprechenden Header Files existieren.

Kochrezeptartig kann man in vielen Fällen einfach so vorgehen:
Man schreibt erst mal den C-Code der Funktion, die man implementieren möchte. Zb fängt man an mit FileA.c
<syntaxhighlight lang="c">
// FileA.c

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionIntA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Jetzt geht man das File, so wie es auch der Compiler macht, von oben nach unten durch schaut den Code durch. Damit functionB aufgerufen werden kann, ist ein Prototyp dafür notwendig. Der kommt aus einem Header File, welches noch nicht existiert, aber im Laufe des Prozesses entstehen und FileB.h heissen wird. FileB.h deshalb, weil die Funktion in FileB.c enthalten ist und man zur Vermeidung von Konfusion die Header Files immer gleich benennt wie die C-Files, nur eben mit einer anderen Dateiendung. FileB.h wird noch geschrieben werden, das hindert uns jetzt aber nicht daran, so zu tun als ob es dieses schon geben würde und ein entsprechender #include ergänzt. (Solange nicht compiliert wird ist das ja auch kein Problem. Irgendwo muss man ja schliesslich mal anfangen die Ergänzungen zu machen.)

<syntaxhighlight lang="c">
// FileA.c

#include "FileB.h"

int VarExtA;
int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
};
</syntaxhighlight>

Gut. Die Variable VarExtB wird ebenfalls über den include hereingezogen
werden. Damit ist FileA.c erst mal vollständig. Da fehlt jetzt erst mal nichts mehr. Alles was in FileA.c vorkommt sind entweder C-Schlüsselwörter, durch FileA.c selbst definiert oder kommt über den #include herein.

Der nächste Schritt ist die Überlegung: Was von dem Zeugs in FileA.C soll von anderer Stelle (von anderen C-Files aus) benutzt und verwendet werden können.
Welche Dinge muss FileA von sich preis geben.

Da sind zu erst mal die beiden Variablen. Was soll mit denen geschehen?
VarExtA soll von aussen zugreifbar sein, VarIntA nicht. Und dann
natürlich die Funktion, die aufrufbar sein soll.

Also beginnt man ein Header File für FileA.c zu schreiben, in das all das
reinkommt, was FileA.c nach aussen sichtbar machen will.

<syntaxhighlight lang="c">
// FileA.h

extern int VarExtA;

int functionA( void );
</syntaxhighlight>

Die Variable kriegt ein extern davor (und wird damit zu einer Deklaration), bei der Funktion wird einfach die Implementierung weggenommen und die somit zu einer Deklaration veränderte Zeile mit einem ; abgeschlossen. Wenn man möchte kann man den so geschaffenen Prototypen auch mit einem extern einleiten. Notwendig ist es aber nicht.

Erneuter Blick aufs Header File. Kommt da irgendwas vor, was nicht
Standard C Schlüsselwort ist? Nein. Nichts.
Also ist dieses Header File somit ebenfalls in sich vollständig.

Zur Sicherheit wird in FileA.c noch einen Include auf das
eigene Header File hinzugefügt, denn dann kann der Compiler überprüfen ob die
Angaben im Header File mit der tatsächlichen Implementierung
übereinstimmen. Und da VarIntA von aussen nicht sichtbar sein soll (auch
nicht durch Tricks), wird sie static gemacht.

<syntaxhighlight lang="c">
// FileA.c

#include "FileA.h"
#include "FileB.h"

int VarExtA;
static int VarIntA;

#define PortpinX PortA.1

int functionA( void )
{
VarIntA = VarExtB;
functionB();
PortpinX = 1;
}
</syntaxhighlight>

Dasselbe für FileB.c. Erst mal einfach runterschreiben
<syntaxhighlight lang="c">
// FileB.c

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;

MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit functionA aufgerufen werden kann, braucht es wieder einen Prototypen. Den
kriegt man über von FileA.h, welches daher includiert wird.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Was noch? VarExtA. Diese Variable wird aber ebenfalls durch den #include als extern Deklaration ins FileB.c hereingezogen und ist somit bei der Übersetzung von FileB.c bekannt. Kommt sonst noch etwas vor? MeinePrivateFunktion. Diese Funktion soll nur in FileB.c benutzt werden und ist für jemanden ausserhalb FileB.c völlig uninteressant. Nichts destotrotz gilt die Regel: compiliert wird von oben nach unten und verwendet werden kann nur etwas, was auch bekannt ist. D.h. bevor der Aufruf der Funktion in functionB gemacht werden kann, muss es einen Protoypen der Funktion geben. Da diese Funktion aber nicht nach 'aussen' exportiert wird, macht man den Protoypen gleich in das C-File mit hinein.

<syntaxhighlight lang="c">
// FileB.c

#include "FileA.h"

int VarExtB;
int VarIntB;

#define SettingB 0x01

void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

Würde man die Funktion vorziehen, so dass der Funktionskörper vor der ersten Verwendung steht, dann würde man auch keinen Protoypen benötigen. Eine Funktionsdefinition fungiert als ihr eigener Protoyp.

Kommt sonst noch etwas vor? Nix mehr. In FileB.c wird sonst nix mehr verwendet was nicht entweder C Schlüsselwort oder im File selber oder durch einen #include reinkommt.

Dann wieder: das Header File für B schreiben. Dabei einfach nur überlegen: was soll von FileB.c nach aussen getragen werden?

<syntaxhighlight lang="c">
// FileB.h

extern int VarExtB;

int functionB( void );
</syntaxhighlight>

und zur Sicherheit wieder ins eigene C-File includen und alle Variablen
(oder auch Funktionen), die von aussen nicht sichtbar sein sollen, als
static markieren.

<syntaxhighlight lang="c">
// FileB.c

#include "FileB.h"
#include "FileA.h"

int VarExtB;
static int VarIntB;

#define SettingB 0x01

static void MeinePrivateFunktion();

int functionB( void )
{
VarExtA = 1;
functionA();
VarIntB = SettingB;
MeinePrivateFunktion();
}

void MeinePrivateFunktion()
{
VarIntB = 8;
}
</syntaxhighlight>

damit bleibt nur noch main.c. Auch dieses wird erst mal einfach runtergeschrieben.

<syntaxhighlight lang="c">
int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionA aufgerufen werden kann, braucht es einen Prototypen. Woher kommt er? Aus FileA.h. Also gleich mal includen
<syntaxhighlight lang="c">
#include "FileA.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Damit functionB aufgerufen werden kann, braucht es einen Prototypen. Wo
kommt der her? Aus FileB.h. Also noch ein #include
<syntaxhighlight lang="c">
#include "FileA.h"
#include "FileB.h"

int c;

int main()
{
functionA();
functionB();
VarExtA = 1;
VarExtB = c;
}
</syntaxhighlight>

Fehlt noch was? VarExtA ist durch den #include von FileA.h bereits
abgedeckt und VarExtB ist durch den #include von FileB.h bereits
abgedeckt. Also fehlt nix mehr. Auch in main.c sind damit alle Sachen
abgedeckt und es ist in sich vollständig.

Das ist der Standardmechanismus:
* Implementierung der Funktionen im C File schreiben
* Überlegen, was von dieser Implementierung von aussen sichtbar sein soll.
* Dasjenige kommt als Deklaration ins Header File, alles andere am besten static machen.
* Für alles im C-File, das seinerseits woanders herkommt, gibt es einen #include, der das jeweils notwendige Header File einbindet.
* Werden im Header File Dinge von woanders benutzt, dann enthält das Header File einen entsprechenden #include
* Jedes File, sowohl Header-File als auch C-File ist in sich vollständig. Werden dort Dinge benutzt, dann müssen diese vor der Verwendung deklariert worden sein. Wie und wo diese Deklaration herkommt, ist dabei zweitrangig. Es kann sein, dass die Deklaration vor der Verwendung steht, es kann aber auch sein, dass die Deklaration über einen weiteren Include mit aufgenommen wird.

= Ich hab da mehrere *.c und *.h Dateien. Was mache ich damit? =

[[Bild:c-flow.svg|right|thumb|260px|C-Programmierung: Workflow]]
Zunächst ist es wichtig, sich zu vergegenwärtigen, wie C-Compiler und Linker zusammenarbeiten. Ein komplettes Programmier-Projekt kann und wird im Normalfall aus mehreren Quelldateien bestehen, die alle zusammengenommen das komplette Programm bilden.

Der Prozess des Erstellens des Programmes geschieht in mehrerern Schritten:
;Compilieren: zunächst werden alle Einzelteile (jede *.c Datei) für sich ''compiliert''. Dabei ensteht aus jeder c-Datei eine sogenannte Object-Datei, in der bereits der Maschinencode für die im c-File programmierten Funktionen enthalten ist
;Linken: die einzelnen Object-Dateien werden mit zusätzlichen Bibliotheken und dem Startup-Code zum fertigen Programm ''gelinkt''.
{{Absatz}}
Angenommen, das komplette Projekt besteht aus 2 Dateien:

;main.c:
<syntaxhighlight lang="c">
int twice (int);

int main()
{
twice (5);
}
</syntaxhighlight>

;func.c:
<syntaxhighlight lang="c">
int twice (int number)
{
return 2 * number;
}
</syntaxhighlight>

Dann werden <tt>main.c</tt> und <tt>func.c</tt> ''unabhängig'' voneinander compiliert. Als Ergebnis erhält man die Dateien <tt>main.o</tt> und <tt>func.o</tt>, die den besagten Object-Code enthalten.
Diese beiden Zwischenergebnisse werden dann zusammen mit Bibliotheken zum fertigen Programm gebunden (gelinkt), das dann ausgeführt werden kann.

Bekommt man also von irgendwo bereits fertige *.c (und zugehörige *.h) Dateien, so genügt es, die *.c Dateien in das Projekt mit aufzunehmen. Dadurch wird das entsprechende C-File compiliert und das Ergebnis davon, das Object-file, wird dann in das fertige Programm mit eingelinkt.

;Achtung: Da jede der C-Dateien unabhängig von allen anderen compiliert wird, bedeutet das auch, dass jede der C-Dateien in sich vollständig sein muss!

Wie eine C-Datei in das Projekt mit aufgenommen wird, hängt im wesentlichen von der benutzten Entwicklungsumgebung ab.

== Makefile ==

Die zusätzliche *.c Datei wird in die SRC Zeile im makefile eingetragen.

== AVR-Studio ==

Hier ist es besonders einfach, eine Datei in das Projekt mit aufzunehmen. Dazu wird im Projektbaum der Knoten "Source Files" aktiviert und mit der rechten Maustaste das Kontextmenü geöffnet. Im Menü wird der Punkt "Add existing Source File(s)" ausgewählt, und anschliessend zeigt man AVR-Studio das zusätzliche C-File. AVR-Studio berücksicht dann diese Datei bei der Projekterzeugung, compiliert es und sorgt dafür, dass es zum fertigen Programm dazugelinkt wird.

=Globale Variablen über mehrere Dateien=
Ein häufiger Problemkreis in der C Programmierung sind auch globale Variablen, die von mehreren *.c Dateien aus benutzt werden sollen. Was hat es damit auf sich?

Zunächst mal muß man bei der Vereinbarung von Variablen zwischen ''Definition'' und ''Deklaration'' unterscheiden:
;Definition: Mit einer Definition wird der Compiler angewiesen, eine Variable tatsächlich zu erzeugen. Damit er das kann, muß ihm selbstverständlich der exakte Datentyp und auch der Name der Variablen zur Verfügung stehen. Eine Definition sorgt also dafür, dass im späteren Programm Speicherplatz für diese Variable reserviert wird
;Deklaration: Mit einer Deklaration teilt man dem Compiler lediglich mit, dass eine Variable existiert. An dieser Stelle soll der Compiler also keinen Speicherplatz reservieren, sondern der Compiler soll einfach nur zur Kenntniss nehmen, daß es eine Variable mit einem bestimmten Namen gibt und von welchem Datentyp sie ist.

Aus obigem folgt sofort, dass eine Definition auch immer eine Deklaration ist. Denn dadurch, daß der Compiler angewiesen wird eine Variable auch tatsächlich zu erzeugen, folgt, dass er dazu auch dieselben Informationen benötigt, die auch in einer Deklaration angegeben werden müssen. Der einzige Unterschied: Bei einer Deklaration trägt der Compiler nur in seinen internen Tabellen ein, dass es diese Variable tatsächlich gibt, während er bei einer Definition zusätzlich auch noch dafür sorgt, dass im fertigen Programm auch Speicher für diese Variable bereitgestellt wird.

Warum ist diese Unterscheidung wichtig?

Weil es in C die sog. ''One Definition Rule'' (ODR). Sie besagt, dass in einem vollständigen Programm, also über alle *.c Dateien gesehen, es für eine Variable nur <b>eine</b> Definition geben darf. Es darf allerdings beliebig viele Deklarationen geben, solange diese Deklarationen alle im Datentyp übereinstimmen. Kurz gesagt: Man darf den Compiler nur einmal auffordern, eine Variable zu erzeugen (Definition), kann sich aber beliebig oft auf diese eine Variable beziehen (Deklarationen). Aber Vorsicht! Da der Compiler jede einzelne *.c Datei für sich alleine übersetzt und dabei kein Wissen von ausserhalb benutzt, obliegt es der Verantwortung des Programmierers dafür zu sorgen, dass alle Deklarationen im Datentyp übereinstimmen. Der Compiler kann diese Einhaltung prinzipbedingt nicht überwachen!

Woran erkennt man eine Definition bzw. Deklaration?

Eine Definition einer globalen Variable steht immer ausserhalb eines Funktionsblocks. Zb.
<syntaxhighlight lang="c">
int MyData; // Globale Variable namens MyData. Sie ist vom Typ int
char Name[30]; // Globales Array
long NrElements = 5; // Globale Variable, die auch noch initialisiert wird
</syntaxhighlight>

Eine Deklaration unterscheidet sich von einer Definition in 2 Punkten
* Es wird das Schlüsselwort <tt>extern</tt> vorangestellt.
* Es kann keine Initialisierung geben. Sobald eine Initialisierung vorhanden ist, wird das Schlüsselwort <tt>extern</tt> ignoriert und aus der Deklaration wird eine Definition.

Beispiele für Deklarationen
<syntaxhighlight lang="c">
extern int MyData;
extern char Name[30];
extern long NrElements;
extern long NrElements = 5; // Achtung: Dies ist eine Definition!
</syntaxhighlight>

Besitzt man also 2 *.c Dateien, main.c und helpers.c, und sollen sich diese beiden Dateien eine globale Variable teilen, so muss in eine Datei eine Definition hinein, während in die andere Datei eine Deklaration derselben Variablen erfolgen muß. Traditionell werden die Definitionen in der *.c-Datei gemacht, die als Hauptdatei des Moduls fungiert, zu der diese Variable konzeptionell gehört. Im Zweifel ist das die *.c Datei, in der main() enthalten ist. Das muss nicht so sein, ist aber eine Konvention, die oft Sinn macht. Alternativ wird auch gerne oft eine eigene *.c Datei (zb. globals.c) gemacht, die einzig und alleine die Defintionen der globalen Variablen enthält.

main.c
<syntaxhighlight lang="c">
int AnzahlElemente; // Dies ist die Definition. Hier wird die globale
// Variable AnzahlElemente tatsächlich erzeugt.

int main()
{
AnzahlElemente = 8;
...
}
</syntaxhighlight>

helpers.c
<syntaxhighlight lang="c">
extern int AnzahlElemente; // Dies ist die Deklaration die auf die globale
// Variable AnzahlElemente in main.c verweist.
// Wichtig: Der Datentyp muss mit dem in main.c
// angegebenen übereinstimmen

void foo()
{
...
j = AnzahlElemente;
AnzahlElemente = 9;
}
</syntaxhighlight>

==Praktische Durchführung==
Besteht ein vollständiges Programm aus mehreren *.c Dateien, dann kann man sich vorstellen, daß es mühsam ist, alle Deklarationen immer auf gleich zu halten. Hier bietet sich der Einsatz eines Header Files an, in der die Deklarationen stehen und welches in die jeweiligen *.c Dateien inkludiert wird

Bsp:

Global.h
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#include "Global.h"

int Anzahl; // auch wenn Global.h inkludiert wurde, so muss es eine
// Definition der Variablen geben. In Global.h sind ja nur
// Deklarationen.

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

bar.c
<syntaxhighlight lang="c">
#include "Global.h"

void bar()
{
...
j = Anzahl;
}
</syntaxhighlight>

Auf diese Art kann man erreichen, dass zumindest alle Deklarationen ein und derselben Variablen in einem Programm übereinstimmen. Die Datei Global.h wird auch in main.c inkludiert, obwohl man das eigentlich nicht müsste, denn dort wird die Variable ja definiert. Durch die Inclusion ermöglicht man aber dem Compiler die Überprüfung ob die Deklaration auch tatsächlich mit der Definition übereinstimmt.

Solange kein Initialisierungen der globalen Variablen notwendig sind, gibt es noch einen weiteren Trick, um sich selbst das Leben und die Verwaltung der globalen Variablen zu erleichtern.
Worin besteht das Problem?
Das Problem besteht darin, dass man bei Einführung einer neuen globalen Variablen an 2 Stellen erweitern muss: Zum einen in der Header-Datei, die die 'extern'-Deklaration der Variablen enthält, zum anderen muss in einer C-Datei die Definition der Variablen erfolgen. Das kann man sich mit etwas Präprozessorarbeit auch einfacher machen:

Global.h
<syntaxhighlight lang="c">
#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int Anzahl;
</syntaxhighlight>

main.c
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"

int main()
{
...
Anzahl = 5;
}
</syntaxhighlight>

foo.c
<syntaxhighlight lang="c">
#include "Global.h"

void foo()
{
...
Anzahl = 8;
...
}
</syntaxhighlight>

Wie funktioniert das Ganze? Im Grunde muss man nur dafür sorgen, dass der Compiler an ''einer'' Stelle das Schlüsselwort '''extern''' ignoriert (hier in main.c) und bei allen anderen Inclusionen beibehält. Dadurch das ein Präprozessor-ifndef benutzt wird, kann dieses erreicht werden. Wird das Header File includiert und ist zu diesem Zeitpunkt das Makro '''EXTERN''' noch nicht definiert, so wird innerhalb des Header Files '''EXTERN''' zu '''extern''' definiert und damit in weiterer Folge im Quelltext '''EXTERN''' durch '''extern''' ersetzt. Wenn daher foo.c das Header File inkludiert, wird die Zeile
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
vom Präprozessor zu
<syntaxhighlight lang="c">
extern int Anzahl;
</syntaxhighlight>
umgewandelt.

In main.c hingegen sieht die Include-Sequenz so aus
<syntaxhighlight lang="c">
#define EXTERN
#include "Global.h"
</syntaxhighlight>
Wenn Global.h bearbeitet wird, existiert bereits ein Makro '''EXTERN''', das auf einen leeren Text expandiert. Dadurch wird verhindert, dass innerhalb von Global.h das Makro '''EXTERN''' mit dem Text '''extern''' belegt wird und
<syntaxhighlight lang="c">
EXTERN int Anzahl;
</syntaxhighlight>
wird daher vom Präprozessor zu
<syntaxhighlight lang="c">
int Anzahl;
</syntaxhighlight>
erweitert, genau wie es benötigt wird.

= Was hat es mit volatile auf sich? =
Immer wieder hört man im Forum die pauschale Aussage "Variablen die in einer ISR verwendet werden, müssen volatile sein". Nun, das ist so nicht ganz richtig.
Welches Problem löst denn eigentlich volatile? Was ist denn das eigentliche Problem, das einer Lösung bedarf?

Das Problem findet sich diesmal im Optimierer eines C Compilers. C Compiler übersetzen, wenn sie optimieren dürfen, den C Code nicht direkt so, wie ihn der Programmierer geschrieben hat, sondern sie versuchen Ressourcen einzusparen. Das kann sowohl Programmspeicher als auch Laufzeit, häufig auch beides gemeinsam sein. Zu diesem Zweck untersuchen sie das Programm und versuchen in der funktional gleichwertigen, in Maschinensprache übersetzen Version, Anweisungen einzusparen. Das dürfen sie auch. Der C-Standard erlaubt Optimierungen, solange die 'As-If'-Regel eingehalten wird. Das bedeutet: Der Compiler darf das Programm umstellen und verändern, solange die Programmergebnisse dieselben bleiben. Eben "As-if" die Optimierung nie stattgefunden hätte.

Nehmen wir ein Beispiel
<syntaxhighlight lang="c">
i = 2;

if( i == 5 )
j = 8;
else
j = 6;
</syntaxhighlight>
In diesem Programmausschnitt darf der Compiler seine Kenntnisse ausnutzen. Er weiß an dieser Stelle, dass i den Wert 2 hat. Damit ist aber auch klar, dass die Bedingung niemals wahr sein kann, denn 2 kann niemals gleich 5 sein. Wenn die Bedingung aber niemals wahr sein kann, dann kann auch die Zuweisung von 8 an j niemals ausgeführt werden. Der Compiler kann also diesen Programmtext zu diesem hier kürzen
<syntaxhighlight lang="c">
i = 2;
j = 6;
</syntaxhighlight>
ohne das sich an den Programmergebnissen etwas ändert. Die zweite Version ist aber kürzer und wird, wegen des Wegfalles des Vergleiches, auch schneller ausgeführt.

Eine andere Form der Optimierung betrifft die Verwaltung von µC-Ressourcen und da wieder ganz speziell die Register. Variablen werden ja erst mal im SRAM-Speicher des µC angelegt. Um mit den Werten von Variablen arbeiten zu können, müssen diese Wert aber vom SRAM-Speicher in µC-Register überführt werden (Register kann man sich wie Speicherstellen in der eigentlichen CPU vorstellen). Nur dort können diese Werte mittels Maschinenbefehlen manipuliert werden.
Jetzt haben aber µC nicht beliebig viele Register. Das bedeutet aber auch, der Compiler muss darüber Buch führen, welche Werte (welche Variablen) gerade in welchen Registern liegen und wenn alle Register belegt sind, muss ein anderes Register freigeräumt werden, in dem der Wert aus dem Register wieder ins SRAM zurück übertragen wird.
Allerdings kostet das auch Zeit. Der Compiler wird daher versuchen, Variablen, die in einem Programmstück oft benötigt werden, für längere Zeit in den Registern zu halten, um das Registerladen bzw. -zurückschreiben einzusparen. Die Grundannahme lautet dabei immer: In Anweisungen, in denen eine Variable nicht vorkommt, kann diese Variable auch nicht verändert werden. Im Programmstück

<syntaxhighlight lang="c">
while( 1 ) {
if( i == 5 )
j = 8;
}
</syntaxhighlight>
gibt es für i keine Möglichkeit, verändert zu werden. Der Compiler kann daher entscheiden, dass er diese Variable, *an dieser Stelle*, gar nicht aus dem SRAM laden muss, sondern sich den entsprechenden Wert in einem Register vorhält und dieses Register ausschließlich dafür reserviert. (Er könnte auch entscheiden, dass der Code nie ausgeführt werden kann, aber das ist eine andere Geschichte)

Der springende Punkt ist nun, dass der Compiler hier eine zu kleine Sicht der Dinge hat. Betrachtet man nur dieses Code Stück, dann gibt es tatsächlich für i keine Möglichkeit, seinen Wert zu verändern. Aber die Dinge ändern sich, wenn Interrupts ins Spiel kommen.

<syntaxhighlight lang="c">
uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
Jetzt gibt es plötzlich eine Möglichkeit, wie i seinen Wert ändern kann: Wenn der entsprechende Interrupt ausgelöst wird, dann wird i auf den Wert 5 gesetzt. i, das ist aber nichts anderes als ein bestimmter Speicherbereich im SRAM. D.h. im SRAM wird die Variable tatsächlich korrekt auf den Wert 5 gesetzt. Nur: Als der Compiler die while-Schleife übersetzt hat, wusste er nichts davon, dass diese Möglichkeit existiert. Er hat entschieden, dass er an dieser Stelle den Wert der Variablen in einem CPU-Register halten wird, um Zugriffe einzusparen. Nur wird diese Kopie des Wertes im Register natürlich nicht verändert, wenn in der ISR das Original von i im SRAM verändert wird.
Fazit: Obwohl die ISR die Variable tatsächlich verändert, kriegt das der Code im while nicht mit, weil der Compiler es mit der Optimierung an dieser Stelle übertrieben hat. In der while-Schleife wird mit einer Kopie des Wertes von i in einem Register gearbeitet und nicht mit dem originalen Wert von i im SRAM.

Und an dieser Stelle kommt jetzt volatile ins Spiel.

volatile teilt dem Compiler mit, dass ausnahmslos alle Zugriffe auf eine Variable auch tatsächlich auszuführen sind und keine Optimierungen gemacht werden dürfen, weil eine Variable auf Wegen benutzt werden kann, die für den Compiler prinzipiell nicht einsichtig sind. Im obigen Beispiel könnte man argumentieren, dass der Compiler ja wohl die ISR bemerken könne und daher feststellen könnte, dass i tatsächlich verändert wird. Aber das stimmt so in der allgemeinen Form nicht. Niemand sagt, dass der Compiler die ISR überhaupt zu Gesicht bekommen muss, die könnte ja auch in einem ganz anderen C File stecken.

<syntaxhighlight lang="c">
volatile uint8_t i;

ISR( irgendein_Interrupt )
{
i = 5;
}

int main()
{
...

while( 1 ) {
if( i == 5 )
j = 8;
}
}
</syntaxhighlight>
wird i volatile gemacht, so verbietet man damit dem Compiler explizit, Annahmen über den Datenfluss von i zu treffen. Innerhalb der Schleife muss also tatsächlich jedes Mal wieder erneut i aus dem SRAM geholt werden und mit 5 verglichen werden. Abkürzungen durch Mehrfachverwendung von Registern oder sonstigen Optimierungstricks sind nicht erlaubt. Und damit ist das Problem gelöst. Wird i in der ISR verändert, so bekommt das auch die Abfrage mit, weil ja jetzt auf jeden Fall auf das Original im SRAM zurückgegriffen wird.

Das Gleiche gilt auch ebenso "in die andere Richtung", wenn also i in der Schleife geändert und in der ISR nur gelesen wird. Auch hier könnte die Optimierung negativ zuschlagen und den Schreibzugriff nur auf eine lokale Kopie der Variable in einem Register durchführen (oder gar ganz wegfallen) lassen, weil der Lesezugriff außerhalb des direkten Programmflusses (in der ISR) für den Compiler nicht ersichtlich ist.

Ein anderes Problem (das ebenfalls mittels volatile gelöst wird) sind Variablen, die tatsächlich im Code überhaupt nie aktiv verändert werden, sondern es sich um Zusatzhardware handelt, die so verschaltet ist, dass sie im Programm in Form einer Variablen auftaucht, z.B. ein Uhren-IC (oder auch ganz banal: Portpins). In diesem Fall wird z.B. die Variable für Sekunden vom Programm gar nicht vom Programm selber verändert, ändert aber trotzdem ihren Inhalt. Die Zusatzhardware selbst macht das. Aus Programmsicht handelt es sich um Speicherzellen, die magisch selbsttätig ihren Wert ändern. Und damit dürfen selbstverständlich auch hier keinerlei Annahmen über den Inhalt der Variablen getroffen werden. Eine derart angebundene externe Hardware nennt man übrigens "memory-mapped", weil sie ihre Werte ins Memory (=Hauptspeicher) mapped (=einblendet).

Allerdings kann volatile nur bei den Variablen sinnvoll genutzt werden, die "von außen" auch änderbar sind. Bei lokalen Variablen, auch statischen, einer Funktion kann das nur passieren, wenn ihre Adresse einer ISR z.B. durch einen globalen Pointer bekannt gemacht wird.
<syntaxhighlight lang="c">
uint8_t *v;
ISR( irgendein_Interrupt )
{
i = 5;
*v = 42;
}

int main()
{
uint8_t i; // kann sich nie unerwartet ändern -> volatile nutzlos, behindert nur Optimizer

volatile uint8_t j; // kann sich unerwartet ändern (über globalen *v)
v = &j;
...
while( 1 ) {
if( i == 5 )
j = 8;
if( j == 5 )
i = 3;
}
}
</syntaxhighlight>

= Konstanten an fester Flash-Adresse =

Wie kann man eine Konstante an entsprechender Adresse im Flash ablegen?

Mehmet Kendi hat eine Lösung für [[AVR Studio]] & [[WinAVR]] in
[http://www.mikrocontroller.net/topic/142704#1453079] angegeben.

= Timer =
== Was macht ein Timer? ==
Oft hört man im Forum die Aussage: Timer sind so kompliziert!

Aber eigentlich stimmt das nicht. Ganz im Gegenteil, Timer sind eigentlich eine sehr einfache Sache. Was genau macht eigentlich ein Timer? Die Antwort lautet: er zählt unabhängig vom restlichen Programmfluss vor sich hin. Und? Was macht er noch? Nichts. Das wars schon. Im Kern ist genau das auch schon alles was ein Timer macht.
[[Bild:Timer_Basis.gif|framed|center|ein 8-Bit Timer bei der Arbeit]]

== Wie schnell macht er es? ==
Aber so einfach ist die Sache dann doch wieder nicht. Da erhebt sich zunächst mal die Frage: wie schnell zählt denn eigentlich so ein Timer? Normalerweise ist der Timer mit der Taktfrequenz des Prozessors gekoppelt, so dass zb bei einer Taktfrequnz von 1Mhz der Timer auch genau so schnell zählt. In 1 Sekunde zählt ein Timer also von 0 bis 1000000, also 1 Mio Zählschritte. Nun kann aber ein beispielsweise 8-Bit Timer nicht bis 1000000 zählen, dazu ist er nicht groß genug. Mit 8 Bit kann man bis 255 zählen. Zählt man da dann noch 1 dazu, dann läuft der Timer über und beginnt wieder bei 0. Man kann daher ruhigen Gewissens sagen: In 1 Sekunde zählt dieser Timer 3906 mal den Bereich von 0 bis 255 (und weiter auf 0) durch (das sind 256 Zählschritte) und zuätzlich schafft er es danach noch bis 64 zu zählen. Denn 3906 * 256 + 64 = 1000000 und wir haben wieder die 1 Mio Zählschritte, die der Timer in 1 Sekunde erledigt.

Das ist ganz schön schnell. Und weil das oft zu schnell ist, hat jeder Timer noch die Möglichkeit sogenannte Vorteiler (Prescaler) vor den Zähltakt zu schalten. Zb einen Vorteiler von 8. Anstelle von 1Mhz bekommt der Timer dann eine Frequenz von 1Mhz / 8 (= 125kHz) präsentiert. Und dementsprechend würde er in 1 Sekunde dann nur noch von 0 bis 125000 (= 1.000.000 / 8) zählen. Als 8 Bit Timer bedeutet das, dass er in 1 Sekunde jetzt nur noch 488 komplette Zyklen 0 bis 255 schafft und dann noch bis 72 zählen kann. Denn 488 * 256 + 72 = 125000

== Das kann aber nicht alles gewesen sein? ==
Bis jetzt ist das alles noch unspektakulär und man fragt sich: Was hab ich jetzt davon, wenn der Timer vor sich hinzählt? Nun, die Situation ändert sich, wenn man weiß, dass man bei bestimmten Ereignissen und/oder Zählerständen etwas auslösen lassen kann. So ist zb. dieser Überlauf von 255 auf 0 so ein Ereignis. Mittels eines Interrupts kann man auf dieses Ereignis reagieren lassen und als Folge davon wird eine Funktion vollautomatisch aufgerufen. Und zwar unabhängig davon, was der µC gerade sonst so tut. Und das ist schon recht cool, denn es bedeutet, dass man regelmäßig zu erfolgende Dinge in so eine ISR (Interrupt Service Routine, die Funktion die aufgerufen wird) stecken kann und der Timer sorgt ganz von alleine dafür, dass diese Funktionalität auch tatsächlich regelmäßig ausgeführt wird. Regelmäßig bedeutet in diesem Fall dann auch wirklich regelmäßig. Denn der Timer zählt ja losgelöst von den restlichen Arbeiten, die der µC sonst so erledigt, vor sich hin. Es spielt keine Rolle, ob der µC gerade mitten in einer komplizierten Berechnung steckt oder nicht. Der Timer zählt vor sich hin, und wenn das entsprechende Ereignis eintritt, wird der Interrupt ausgelöst. Und wenn der entsprechende Interrupt mit einer ISR-Funktion gekoppelt ist, dann wird der normale Programmfluss unterbrochen und der µC arbeitet genau diese eine Funktion ab. Und zwar in regelmässigen Zeitabständen, weil ja auch der Interrupt regelmässig auftritt.
[[Bild:Timer_ISR.gif|framed|center|ein 8-Bit Timer löst durch seinen Overflow regelmäßige ISR Aufrufe aus]]
Gut, beispielsweise 488 mal in der Sekunde mag für so manchen Zweck zu oft sein, aber es gibt ja auch noch andere Vorteiler (welche steht im Datenblatt) und dann kann man ja auch innerhalb der ISR in einer lokalen Variablen mitzählen und zb nur bei jedem 2.ten Aufruf eine Aktion machen, die dann nur noch 244 mal in der Sekunde ausgeführt wird. Hier gibt es also mehrere Möglichkeiten, wie man die Aufrufhäufigkeit weiter herunterteilen kann, so dass man sich der Zahl annähert, die man benötigt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

//
// der Timer wird mit 1Mhz getaktet. Vorteiler ist 8
// d.h. der Timer läuft mit 125kHz und würde daher in 1 Sekunde
// von 0 bis 124999 zaehlen.
// Aber nach jeweils 256 Zaehlungen erfolgt ein Overflow.
// Daher werden in 1 Sekunde 125000 / 256 = 488.28125 Overflows erzeugt
// Oder anders ausgedrückt: 1 / 488.2815 = 0.002048
// alle 0.002048 Sekunden erfolgt ein Overflow
//
ISR( TIMER0_OVF_vect ) // Overflow Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) { // nur bei jedem 200.ten Aufruf. Effektiv teilt dieses die
// die Aufruffrequenz des nachfolgenden Codes nochmal um
swTeiler = 0; // einen Faktor 200. Der nachfolgende Code wird daher nicht
// alle 0.002 Sekunden sondern alle 0.4096 Sekunden ausgeführt.
// Das reicht, dass man eine LED am Port schon blinken sieht.
PORTD = PORTD ^ 0xFF; // alle Bits am Port umdrehen, einfach damit sich was tut
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK |= (1<<TOIE0); // den Overflow Interrupt des Timers freigeben
TCCR0 = (1<<CS01); // Vorteiler 8, jetzt zählt der Timer bereits

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmäßig aufgerufen wird
</syntaxhighlight>

== CTC Modus ==
Manchmal reicht das aber nicht. Benötigt man zb nicht 488 sondern möglichst genau 500 ISR Aufrufe in der Sekunde, so wird man weder mit Vorteiler noch durch Softwaremässiges Weiterteilen in der ISR zum Ziel kommen. Man kann natürlich die Taktfrequenz des kompletten Systems soweit umstellen, dass sich das alles ausgeht, aber oft ist das einfach nicht möglich. Was tun?

Die Sache wäre einfacher, wenn man dem Timer vorschreiben könnte, nicht einfach nur von 0 bis 255 zu zählen, sondern wenn man ihm eine Obergrenze vorgeben könnte. Denn dann könnte man sich eine Obergrenze so bestimmen, dass dieser neue Zählbereich in 1 Sekunde ganz genau so oft durchlaufen werden kann, wie man es benötigt. Und hier kommt der sog. <b>CTC</b> Modus ins Spiel. Denn genau darin besteht sein Wesen: Man gibt dem Timer eine Obergrenze vor. Erreicht seine Zählung diesen Wert, so wird der Timer auf 0 zurückgesetzt und beginnt wieder von vorne. Genau das was wir benötigen. Wollen wir exakt 500 ISR Ausfrufe in der Sekunde haben (bei 1 Mhz Systemtakt), dann wählen wir einen Vorteiler von 8 und setzen die Obergrenze auf 250-1 (nicht vergessen: wir brauchen 250 Zählschritte, das bedeutet der Timer muss von 0 bis 249 zählen, denn auch der Überlauf von 249 zurück auf 0 ist ein Zählschritt). Der Timer taktet dann mit 1Mhz / 8 = 125kHz und da nach jeweils 250 Zählschritten die Obergrenze erreicht ist, wird diese Obergrenze in 1 Sekunde 125000 / 250 = 500 mal erreicht. Genau so wie wir das wollten.
Wie wird dem Timer nun mitgeteilt, dass er eine spezielle Obergrenze benutzen soll? Nun, jeder Timer hat verschiedene Modi. Welche das bei einem konkreten µC und bei einem konkreten Timer genau sind, findet sich im Datenblatt im Abschnitt über die Timer. Normalerweise ist immer eines der letzteren Abschnitte eines jeden Kapitels im Datenblatt das interessantere: "Register Summary" oder "Register Description" genannt (die Datenblätter sind da nicht ganz einheitlich). So auch hier.
[[Bild:FAQ_Datenblatt_Timer_Mega16.png|framed|center|Auszug aus dem Atmel Datenblatt für den Mega16 - Suche im Datenblatt]]
In jedem Atmel Datenblatt findet sich bei jedem Timer immer auch besagter Abschnitt (im Inhaltsverzeichnis beim Kapitel über den jeweiligen Timer suchen. Im Datenblatt-PDF daher immer das Inhaltsverzeichnis anzeigen lassen!), und in diesem Abschnitt gibt es eine Tabelle, aus der hervorgeht, welche Modi es gibt, welche Bits dazu in den Konfigurationsregistern gesetzt werden müssen, wie sich dann die Obergrenze des Timer-Zählbereichs zusammensetzt und noch ein paar Angaben mehr. Beim Mega16 findet sich diese Tabelle für den Timer 0 zb auf Seite 83 und dort ist es die Tabelle 14.2. Diese Tabelle sieht im Datenblatt so aus

<center>
{| {{Tabelle}}
|- style="background-color:#ffddcc"
! Mode || WGM01 || WGM00 || Timer/Counter || TOP || Update of || TOV0 Flag
|- style="background-color:#ffddcc"
! || (CTC0) || (PWM0) || Mode of Operation || || OCR0 || Set-on
|-
| 0 || 0 || 0 || Normal || 0xFF || Immediate || MAX
|-
| 1 || 0 || 1 || PWM, Phase Correct || 0xFF || TOP|| BOTTOM
|-
| 2 || 1 || 0 || CTC || OCR0 || Immediate || MAX
|-
| 3 || 1 || 1 || Fast PWM || 0xFF || BOTTOM || MAX
|}
</center>

Dort beginnt man mit der Recherche und sucht sich die Bits für den gewünschten Modus raus. Mit diesen Bits sieht man dann in den Konfigurationsregistern nach, welches Bit zu welchem Register gehört und setzt es ganz einfach. In unserem Fall möchten wir den CTC Modus, also den Modus 2. Dazu muss das Bit WGM01 gesetzt werden und WGM00 muss auf 0 bleiben. Im Datenblatt ein wenig zurückscrollen bringt ans Licht, dass das Bit WGM01 im Konfigurationsregister TCCR0 angesiedelt ist. Weiters entnehmen wir der Tabelle, dass der Timer bis zum Wert in OCR0 zählen wird (die Spalte <b>TOP</b>). Dort hinein müssen also die 250-1 als Obergrenze geschrieben werden.

Wichtig ist auch noch: Dieser Spezialmodus CTC löst keinen Overflow Interrupt aus, sondern einen sog. Compare Match Interrupt. Dies deshalb, weil die gewünschte Obergrenze ja laut Datenblatt in eines der sog. Compare Match Register geschrieben werden muss (OCR0). Das sind Spezialregister, die nach jedem Zählvorgang mit dem Zählregister verglichen werden. Stimmt ihr Inhalt mit dem des Zählregisters überein, so hat man einen Compare-Match und kann daran wieder eine Aktion (ISR) knüpfen. In diesem speziellen Fall des CTC Modus beinhaltet dieser Compare Match dann auch noch das automatische Rücksetzen des Timers auf 0.

Und natürlich können auch mehrere Techniken kombiniert werden. Z. B. CTC Modus und zusätzliches weiteres softwaremässiges Herunterteilen in der ISR sieht dann so aus:

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>

ISR( TIMER0_COMP_vect ) // Compare Match Interrupt Vector
{
static uint8_t swTeiler = 0;

swTeiler++;
if( swTeiler == 200 ) {
swTeiler = 0;
PORTD = PORTD ^ 0xFF;
}
}

int main()
{
DDRD = 0xFF; // irgendein Port, damit wir auch was sehen

TIMSK = (1<<OCIE0); // den Output Compare Interrupt des Timers freigeben
OCR0 = 250 - 1; // nach 250 Zaehlschritten -> Interrupt und Timer auf 0
TCCR0 = (1<<WGM01) | (1<<CS01); // Vorteiler 8, CTC Modus

sei(); // und Interrupts generell freigeben

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
} // der Timer selbst sorgt dafür, dass die ISR Funktion
} // regelmässig aufgerufen wird
</syntaxhighlight>

== Fast PWM ==

Aber der Timer kann noch mehr. Wenn der Timer so vor sich hinzählt, dann kann man bestimmte Output-Pins des µC an diesen Timer koppeln. Der Timer kann dann diesen Pin bei erreichen von bestimmten Zählerständen ganz von alleine wahlweise auf 0 schalten, auf 1 schalten oder umdrehen.

Was passiert da genau? Im folgenden sei von der einfachsten Form der PWM auf einem Mega16 ausgegangen: Wenn der Timer in seiner Zählerei bei 0 ist, dann schaltet er den Pin auf 1, bei einem bestimmten Zählerstand soll er den Pin wieder auf 0 zurücksetzen und ansonsten soll der Timer wie gewohnt laufend von 0 bis 255 durchzählen.
Es ist die Rede vom Timer-Modus 3, siehe die vorhergehende Tabelle aus dem Datenblatt.

Der Tabelle entnehmen wir wieder: Die Bits WGM01 und WGM00 müssen auf 1 gestellt werden. Der TOP Wert (also der Wert, bis zu dem der Timer zählt) ist 0xFF (also 255) und das OCR0 Register steuert, bei welchem Zählerstand die Timerhardware den Pin wieder auf 0 zurück schaltet. Das Einschalten auf 1 ist vorgegeben (auch das kann man ändern, dazu später mehr).

Stellt man also genau diese Konfiguration her und schreibt in das Register OCR0 beispielsweise den Wert 253, dann beginnt der Timer bei 0 zu zählen, wobei der den Ausgangspin auf 1 schaltet. Wird der Zählerstand 253 erreicht, dann schaltet der Timer den Pin wieder auf 0 zurück und zählt weiter bis 255 um dann wieder erneut bei 0 zu beginnen (und den Ausgansg-Pin wieder auf 1 zu schalten). Der Ausgangspin ist in diesem Fall also die meiste Zeit auf 1 und nur ganz kurz (während der Timer von 253 bis 255 zählt) auf 0.

Schreibt am auf der anderen Seite in das Register OCR0 den Wert 3, dann passiert konzeptionell genau dasselbe nur mit anderen Zahlenwerten. Der Timer beginnt bei 0 zu zählen und schaltet den Ausgansgpin auf 1. Aber diesmal ist es bereits beim Zählerstand 3 so weit: Der Zählerstand stimmt mit dem Wert in OCR0 überein und als Folge davon wird der Ausgangspin wieder auf 0 gestellt. Der Timer zählt natürlich wie immer weiter bis 255 ehe dann das ganze Spiel wieder von vorne beginnt. In diesem Fall war also der Ausgangspin nur ganz kurze Zeit auf 1 (nämich in der Zeit, die der Timer benötigt um von 0 bis 3 zu zählen) und dann die meiste Zeit auf 0. Und genau darum geht es bei PWM: Mit dem Register OCR0 lässt sich daher der zeitliche Anteil steuern, in dem der Pin auf 1 liegt.

<syntaxhighlight lang="c">
// Für einen Mega16.
// Andere Prozessoren: siehe Datenblatt wie die Timerkonfiguration einzustellen ist

#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>

int main()
{
uint8_t i;

DDRB |= (1<<PB3); // PB3 auf Ausgang stellen. Dieser Pin
// trägt auch die Bezeichnung OC0 und ist der Pin
// an dem der Timer 0 seine PWM ausgibt

OCR0 = 250;
TCCR0 = (1<<WGM01) | (1<<WGM00) | (1<<CS01); // Vorteiler 8, Fast PWM 8 Bit
TCCR0 = (1<<COM01);

while( 1 )
{ // hier braucht nichts mehr gemacht werden.
// der Timer selbst sorgt dafür, dass die PWM läuft
// wir wollen aber ein wenig Action haben.
// Also setzen wir das OCR0 Register auf verschiedene
// Werte, damit eine angeschlossene LED unterschiedliche
// Helligkeiten zeigt
OCR0 = 30;
_delay_ms( 1000 );
OCR0 = 200;
_delay_ms( 1000 );

for( i = 0; i < 255; ++i ) {
OCR0 = i;
_delay_ms( 10 );
}
}
}
</syntaxhighlight>

Bleibt noch das gesetzte Bit COM01. Was hat es damit auf sich? Bisher war immer die Rede davon, das der Ausganspin bei einem Zählerstand von 0 auf 1 geschaltet wird usw. Das regelt genau dieses Bit. Im Datenblatt findet sich die Tabelle 14.4 auf der Seite 83, die genau regelt welche Bedeutung die Bits COM01 bzw COM00 haben, wenn der Timer Modus auf Fast-PWM eingestellt ist. Achtung: Je nach Timer-Modus haben diese Bits andere Bedeutungen! Man muss sich also immer die zum jeweiligen Timer-Modus gehörende Tabelle im Datenblatt suchen.

<references />

[[Kategorie:C]]
[[Kategorie:avr-gcc]]

2012-12-15T11:02:21Z

Cmf: /* Siehe auch */

2012-12-15T10:42:13Z

Cmf: /* Die Lösung */

Transistor-Übersicht

2012-06-08T15:13:10Z

Cmf: /* NPN */

Im Forum wird immer wieder gefragt, welcher [[Transistor]] für eine bestimmte Anwendung passend ist, dafür wurde dieser Wikieintrag angelegt. Wie in der [[Mosfet-Übersicht]] und der [[Dioden-Übersicht]] soll hier eine Liste entstehen mit gängigen Bipolar-Transistoren, die leicht erhältlich sind. Für die Typbezeichnung siehe [[Kennzeichnung von Halbleitern]]. Eine allgemeine Übersicht über verschiedene Bauteile gibt es hier: [[Standardbauelemente]].

== NPN ==
'''Bemerkungen:'''
*U<sub>CE</sub> = Maximale Kollektor-Emitter-Spannung bei I<sub>C</sub> = 0
*I<sub>C</sub> = Maximaler Kollektorstrom
*SOT-32 = TO-126

(Tabelle mit Klick auf Überschrift sortierbar)
{| {{Tabelle}} class="sortable" id="npn"
|- style="background-color:#eeeeee"
! Bezeichnung || Package || U<sub>CE</sub>/V || I<sub>C</sub>/A || β (Beta)|| β@IC|| V<sub>CEsat</sub> || P<sub>tot</sub>/W|| f<sub>G</sub>/MHz|| Bemerkung|| Lieferant|| Datenblatt|| ca. Preis/€
|-
|[http://www.mikrocontroller.net/part/PN2222 PN2222]
|TO-92
|30
|0,8
|100-300
|
|1
|0.6
|300
|Allrounder
|Rei
|[http://www.reichelt.de/?ACTION=7;LA=3;INDEX=0;FILENAME=A100%252FPN2222A_NXP.pdf National]
|0.06
|-
|[http://www.mikrocontroller.net/part/2N3904 2N3904]
|TO-92
|40
|0.2
|100-300
|
|
|0.5
|300
|Schalttransistor
|Rei
|[http://www.fairchildsemi.com/ds/2N/2N3904.pdf Fairchild]
|0.04
|-
|[http://www.mikrocontroller.net/part/2N3055 2N3055]
|TO-3
|60
|15
|20-70
|
|
|115
|2.5
|Leistungstransistor
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/2466/MOSPEC/2N3055.html alldatasheet.com]
|0.40
|-
|[http://www.mikrocontroller.net/part/BC107 BC107]B
|TO-18
|45
|0.1
|200-450
|
|
|0.3
|300
|
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/45348/SIEMENS/BC107B.html alldatasheet.com]
|0.23
|-
|[http://www.mikrocontroller.net/part/BC547 BC547]B
|TO-92
|45
|0.1
|125-500
|
|0.9
|0.625
|300
|Schalttransistor
|Rei
|[http://www.fairchildsemi.com/ds/BC/BC547.pdf Fairchild]
|0.04
|-
|[http://www.mikrocontroller.net/part/BD679 BD679]A
|TO-126
|80
|4
|750
|
|
|40
|
|Darlington
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/11588/ONSEMI/BD679A.html alldatasheet.com]
|0.21
|-
|[http://www.mikrocontroller.net/part/MPSA42 MPSA42]
|TO-92
|300
|0.5
|40
|
|
|0.625
|50
|hohe Spannung
|Rei
|[http://www.fairchildsemi.com/ds/MP/MPSA42.pdf Fairchild]
|0.05
|-
|[http://www.mikrocontroller.net/part/BC337 BC337]
|TO-92
|45
|0.8
|100-630
|100
|0.7
|0.625
|210
|
|Rei
|[http://www.fairchildsemi.com/ds/BC%2FBC337.pdf Fairchild]
|0.05
|-
|[http://www.mikrocontroller.net/part/BC368 BC368]
|TO-92
|20
|1.5
|100-450
|
|
|0.625
|40
|
|Rei
|[http://www.fairchildsemi.com/ds/BC/BC368.pdf Fairchild]
|0.08
|-
|[http://www.mikrocontroller.net/part/FMMT617 FMMT617]
|SOT-23
|15
|3
|60-300
|300
|0.15
|0.625
|
|Schalttransistor
|Rei
|[http://www.zetex.com/3.0/pdf/FMMT617.pdf Zetex]
|0.27
|-
|[http://www.mikrocontroller.net/part/FMMT619 FMMT619]
|SOT-23
|50
|2
|40-400
|200
|0.2
|0.625
|
|Schalttransistor
|Rei
|[http://www.zetex.com/3.0/pdf/FMMT619.pdf Zetex]
|0.32
|-
|[http://www.mikrocontroller.net/part/FMMT625 FMMT625]
|SOT-23
|150
|1
|15-400
|45
|0.2
|0.625
|
|Schalttransistor
|Rei
|[http://www.zetex.com/3.0/pdf/FMMT625.pdf Zetex]
|0.32
|-
| [http://www.mikrocontroller.net/part/MJ15003 MJ15003]
| TO-3
| 140
| 20
| 25-150
|
|
| 250
| 2
| Leistungstransistor
| Rei Far
| [http://www.alldatasheet.com/datasheet-pdf/pdf/4799/MOTOROLA/MJ15004.html alldatasheet.com]
| 1.55
|-
| [http://www.mikrocontroller.net/part/BD131 BD131]
| TO-126
| 45
| 3
| 30-70
|
|
| 15
| 60
| Mittlere Leistung, guter Allrounder
| Rei
| [http://www.datasheetcatalog.org/datasheet/philips/BD131.pdf Fairchild]
| 0.21
|-
|[http://www.mikrocontroller.net/part/BC517 BC517]
|TO-92
|30
|0.5
|30000
|
|1
|0.6
|200
|Darlington
|Rei
|[http://www.nxp.com/documents/data_sheet/BC517.pdf NXP]
|0.08
|-
|[http://www.mikrocontroller.net/part/BCW66 BCW66]
|SOT-23
|45
|0.8
|100-630
|
|0.9
|0.36
|170
|
|Rei
|[http://www.diodes.com/datasheets/BCW66.pdf Zetex]
|0.041
|-
|[http://www.mikrocontroller.net/part/BFR92 BFR92]
|SOT-23
|15
|0.3
|50
|
|
|0.2
|5000
| Hochfrequenz
|Rei ...
|
|0.16
|-
|[http://www.mikrocontroller.net/part/BUX85 BUX85]
|TO-220
|450
|2
|>35
|
|
|40
|12
|
|Rei Con
|[http://www.bourns.com/pdfs/bux85.pdf bourns.com]
|0.48
|-
|[http://www.mikrocontroller.net/part/TIP41C TIP41C]
|TO-220
|100
|6
|15
|3000
|1.5
|65
|3
|
|csd Rei Con
|
|0.24
|-
|BSR14
|SOT23
|40
|0.8
|100
|0.15
|1
|0.35
|300
|
|Rei
|[http://www.nxp.com/documents/data_sheet/BSR13_BSR14.pdf NXP]
|0.08
|-
|[http://www.mikrocontroller.net/part/BF199 BF199]
|TO-92
|25
|0.05
|
|38
|0.2
|0.35
|700
| alter HF-Transistor
|Rei Con Far ...
|[http://www.nxp.com/documents/data_sheet/BF199.pdf NXP]
|0.35
|-
|}

== PNP ==
(Tabelle mit Klick auf Überschrift sortierbar)
{| {{Tabelle}} class="sortable" id="pkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! U<sub>CE</sub>/V
! I<sub>C</sub>/A
! β (Beta)
! P<sub>tot</sub>/W
! f<sub>G</sub>/MHz
! Bemerkung
! Lieferant
! Datenblatt
! ca. Preis/€
|-
|[http://www.mikrocontroller.net/part/2N3906 2N3906]
|TO-92
|40
|0.2
|100-300
|0.5
|250
|
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/15078/PHILIPS/2N3906.html alldatasheet.com]
|0.05
|-
|[http://www.mikrocontroller.net/part/BC560 BC560]
|TO-92
|45
|0,1
|110-800
|0.5
|150
|
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BC560 alldatasheet.com]
|0.04
|-
|[http://www.mikrocontroller.net/part/BC327 BC327]
|TO-92
|45
|0.8
|100-630
|0.625
|
|Komplement zu BC337
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BC327 alldatasheet.com]
|0.04
|-
|[http://www.mikrocontroller.net/part/BC369 BC369]
|TO-92
|20
|1.5
|100-400
|0.625
|
|Komplement zu BC368
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BC369 alldatasheet.com]
|0.08
|-
|[http://www.mikrocontroller.net/part/FMMT717 FMMT717]
|SOT-23
|12
|2.5
|50-300
|0.625
|
|Komplement zu [http://www.mikrocontroller.net/part/FMMT617 FMMT617]
|Rei
|[http://www.zetex.com/3.0/pdf/FMMT717.pdf Zetex]
|0.19
|-
|[http://www.mikrocontroller.net/part/BD438 BD438]
|TO-126
|45
|4
|30-140
|36
|3
|
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=BD438 alldatasheet.com]
|0.17
|-
|[http://www.mikrocontroller.net/part/MJ2955 MJ2955]
|TO-3
|60
|15
|20-70
|115
|2.5
|2N3055 Komplement
|Rei
|[http://alldatasheet.com/view.jsp?Searchword=MJ2955 alldatasheet.com]
|0.40
|-
| [http://www.mikrocontroller.net/part/BD132 BD132]
| TO-126
| 45
| 3
| 30-120
| 15
| 60
| Komplement zu BD131
| Rei,?
| [http://www.alldatasheet.com/datasheet-pdf/pdf/16168/PHILIPS/BD132.html alldatasheet.com]
| 0.20
|-
|[http://www.mikrocontroller.net/part/BC516 BC516]
|TO-92
|30
|0.5
|30000
|0.5
|220
|Komplement zum BC517
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/15078/PHILIPS/2N3906.html alldatasheet.com]
|0.12
|-
|[http://www.mikrocontroller.net/part/BCP53 BCP53]
|SOT223
|80
|1
|
|1.3
|115
|
|Rei
|[http://www.datasheetcatalog.net/de/datasheets_pdf/B/C/P/5/BCP52-16.shtml datasheetcatalog.com]
|0.17
|-
|[http://www.mikrocontroller.net/part/BDP950 BDP950]
|SOT223
|60
|3
|
|3
|100
|
|Rei
|[http://www.datasheetcatalog.com/datasheets_pdf/B/D/P/9/BDP950.shtml datasheetcatalog.com]
|0.29
|-
|[http://www.mikrocontroller.net/part/BCW67 BCW67]
|SOT-23
|42
|0.8
|100-630
|0.32
|200
|
|Rei
|[http://pdf1.alldatasheet.com/datasheet-pdf/view/79166/INFINEON/BCW67.html alldatasheet.com]
|0.041
|-
|[http://www.mikrocontroller.net/part/MJ2955 MJ2955]
|T0-3
|60
|15
|20-70
|115
|
|Komplement zu 2N3055, Leistungstransistor
|Rei
|[http://www.datasheetcatalog.net/de/datasheets_pdf/M/J/2/9/MJ2955.shtml datasheetcatalog]
|0.70
|-
|BSR15
|SOT23
|40
|0.8
|100
|0.25
|200
|Schalttransistor
|Rei
|[http://www.nxp.com/documents/data_sheet/BSR15_BSR16.pdf NXP]
|0.09
|}

== Transistor-Array ==
(Tabelle mit Klick auf Überschrift sortierbar)
{| {{Tabelle}} class="sortable" id="pkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! U<sub>CE</sub>/V
! I<sub>C</sub>/A
! β (Beta)
! P<sub>tot</sub>/W
! f<sub>T</sub>/MHz
! Bemerkung
! Lieferant
! Datenblatt
! ca. Preis/€
|-
| [http://www.mikrocontroller.net/part/NTE912 NTE912]
| DIL-14
| -
| -
| -
| -
| -
| 5 NPN-Transistoren
| Far
| [http://www.nteinc.com/specs/900to999/pdf/nte912.pdf NTE]
| 3.50
|-
| [http://www.mikrocontroller.net/part/CA3086 CA3086]
| DIL-14
| -
| -
| -
| -
| -
| 5 NPN-Transistoren, abgekündigt
| eBay
| [http://www.intersil.com/data/fn/fn483.pdf Intersil]
| 0.50
|-
| [http://www.mikrocontroller.net/part/BCV61 BCV61]
| SOT143
| 30
| 0.1
| 100-800
| 0.25
| 100
| 2 NPN-Transistoren für Stromspiegel
| Rei, Far
| [http://www.alldatasheet.com/view.jsp?Searchword=BCV61 alldatasheet.com]
| 0.14
|-
| [http://www.mikrocontroller.net/part/BCV62 BCV62]
| SOT143
| 30
| 0.1
| 100-800
| 0.25
| 100
| 2 PNP-Transistoren für Stromspiegel
| Rei, Far
| [http://www.alldatasheet.com/view.jsp?Searchword=BCV62 alldatasheet.com]
| 0.19
|-
| [http://www.mikrocontroller.net/part/ULN2801 ULN2801] [http://www.mikrocontroller.net/part/ULN2802 ULN2802] [http://www.mikrocontroller.net/part/ULN2803 ULN2803] [http://www.mikrocontroller.net/part/ULN2804 ULN2804]
| DIL18 SO18
| 50
| 0.35
|
| 1
| kHz
| 8x Low-Side NPN-Darlington, Freilaufdiode, max 500mA insgesamt
| Rei, Far, alle
| [http://www.alldatasheet.com/view.jsp?Searchword=BCV62 alldatasheet.com]
| 0.35 - 0,50
|-
| [http://www.mikrocontroller.net/part/UDN2981 UDN2981]
| DIL18 SO18
| 50
| 0.35
|
| 1
| kHz
| 8x High-Side NPN-Darlington, Freilaufdiode, max 500mA insgesamt, obsolete, Ersatz: Micrel MIC2981
| Rei, Far
| [http://www.allegromicro.com/en/Products/Part_Numbers/2981/2981.pdf Allegro]
| 1.75
|}

== Vollbrücke, Halbbrücke ==
(Tabelle mit Klick auf Überschrift sortierbar)
{| {{Tabelle}} class="sortable" id="pkanalmosfets"
|- style="background-color:#eeeeee"
! Bezeichnung
! Package
! U<sub>CE</sub>/V
! I<sub>C</sub>/A
! β (Beta)
! P<sub>tot</sub>/W
! f<sub>T</sub>/MHz
! Bemerkung
! Lieferant
! Datenblatt
! ca. Preis/€
|-
| ZDT 6790 TA
| SM-8
| -
| -
| -
| -
| -
| Halbbrücke 1x NPN, 1x PNP
| Rei
| [http://www.datasheetarchive.com/pdf-datasheets/Datasheets-311/133888.html Datasheetarchive.com]
| 0,74 €
|-
| ZHB6792
| SM-8
| -
| -
| -
| -
| -
| H-Brücke 2x NPN, 2x PNP
| Rei
| [http://www.diodes.com/zetex/_pdfs/3.0/pdf/ZHB6792.pdf Diodes.com]
| 1,70 €
|-
|}

== Lieferantenübersicht ==
* [Rei] [[Elektronikversender#Reichelt|Reichelt]]: http://www.reichelt.de
* [Con] [[Elektronikversender#Conrad|Conrad-Elektronik]]: http://www.conrad.de
* [csd] [[Elektronikversender#csd-electronics|CSD-Electronics]]: http://www.csd-electronics.de/
* [Kes] [[Elektronikversender#Kessler|Kessler]]: http://www.kessler-elektronik.de
* [Far] [[Elektronikversender#Farnell|Farnell]]: http://www.farnell.de

== Parametrische Suche beim Hersteller ==
* [http://www.infineon.com/cms/de/product/channel.html?channel=db3a304319c6f18c011a14e8a6de25fc Infineon]
* [http://www.diodes.com/zetex/?ztx=3.0/transistor_search Diodes (vormals Zetex)]
* [http://www.nxp.com/#/homepage/cb=%5Bt%3Dp%2Cp%3D%2F71078%2F47196%5D%7Cpp%3D%5Bt%3Dpfp%2Ci%3D47196%5D NXP Small-Signal]
* [http://www.nxp.com/#/homepage/cb=%5Bt%3Dp%2Cp%3D%2F71078%2F41781%5D%7Cpp%3D%5Bt%3Dpfp%2Ci%3D41781%5D NXP low VCEsat]
* [http://www.onsemi.com/PowerSolutions/taxonomy.do?id=797&lctn=home ONsemi]

[[Category:Bauteile]]

2012-05-16T20:41:17Z

Cmf: Bild hinzugefügt

[[Bild:Quarz_offen.jpg|right|framed|Zwei geöffnete Quarze]]
Dieser Artikel beinhaltet Informationen zu Quarzen im Allgemeinen. Für die Verwendung zusammen mit AVRs siehe [[Quarze und AVR]]

Ein Quarz, eigentlich "Schwingquarz", ist ein Bauteil zu Erzeugung einer bestimmten Frequenz. Die Genauigkeit von Quarzen liegt bei 10-100ppm (1ppm = 0,0001 %) und wird somit nur noch vom [[Quarzoszillator]] überboten.

= Verwendung =
Quarze sind in folgenden Situationen sinnvoll / notwendig:

* Interner Oszillator des µC zu langsam / ungenau
* In der Funktechnik zur genauen und stabilen Fequenzerzeugung
* Als Quarzfilter in Empfängern?

= Frequenzen =

"Runde" Frequenzen (4MHz, 8MHz, 10MHz....) sind meist leichter erhältlich und haben den Vorteil, dass man Verzögerungsschleifen und Rechendauern relativ leicht errechnen kann.

12MHz: Aus dieser Frequenz erzeugen Software-USB Programme oft den für USB notwendigen Takt.
0,032768Mhz: Diese Quarze werden häufig als Uhrenquarze verwendet

"Baudraten"-Frequenzen (siehe [[Baudratenquarz]]e sind ganzzahlige Vielfache der bei RS232 üblichen Baudraten. Mit Baudraten-Frequenzen kann man mit den im Kontroller enthaltenen Teilern exakte Baudraten erreichen, mit "runden" Frequenzen entstehen u.U. einige Prozent Fehler.

= Quarze in Eagle =

In Eagle findet man Quarze in der Bibliothek "Crystal" in der Untergruppe "Crystal".
Im Forum wurde eine Bibliothek mit mehreren SMD-Quarzen und Oszillatoren hochgeladen: http://www.mikrocontroller.net/articles/Eagle-Bibliotheken#Kristalle_und_Oszillatoren

= Siehe auch =
Wikipedia: [http://de.wikipedia.org/wiki/Schwingquarz]

Datei:Quarz offen.jpg

2012-05-16T20:39:00Z

Cmf:

Quarze und AVR

2012-05-16T20:34:45Z

Cmf:

Diese Seite behandelt Quarze im Zusammenhang mit AVRs. Für allgemeine Informationen zum Thema siehe [[Quarz]].

Die Genauigkeit von Quarzen liegt bei 10-100ppm (1ppm = 0,0001 %) und wird somit nur noch vom [[Oszillator#Quarzoszillator|Quarzoszillator]] überboten. Außerdem sind Quarze im Gegensatz zum internen RC-Oszillator weniger temperaturunabhängig.

= Verwendung =
Quarze sind in folgenden Situationen sinnvoll / notwendig:

* Interner Oszillator des µC zu langsam
* Interner Oszillator des µC zu ungenau
**Bei Verwendung des [[UART]]
**Bei zeitkritischen Anwendungen wie z.B. einer Uhr

= Wahl der richtigen Frequenz =
Vor allem als Anfänger denkt man sich, ''ich kaufe einfach mal 10MHz, das ist eine so schön gerade Zahl''. Allerdings sind diese Quarze nur in den seltensten Fällen sinnvoll. Viel sinnvoller sind [[Baudratenquarz]]e. "Baudraten"-Frequenzen sind ganzzahlige Vielfache der bei RS232 üblichen Baudraten. Mit Baudrate-Frequenz kann man exakte Baudraten erreichen, mit "runden" Frequenzen entstehen Fehler, weshalb oft nur sehr niedrige Baudraten möglich sind.

"Runde" Frequenzen (4MHz, 8MHz, 10MHz....) sind meist leichter erhältlich und haben den Vorteil, dass man Verzögerungsschleifen und Rechendauern relativ leicht errechnen kann.

= Anschluss =
[[Bild:Quarz_Anschluss_AVR.png|right|framed]]
Die Kapazitäten von C1 und C2 entsprechen '''nicht''' der Lastkapazität des Quarzes!
Sie errechnen sich folgendermaßen:

C=2xCL-(CP+CI)

*CP: Leiterbahnen bedingte Kapazität
*CI: Portbedingte Kapazität
*CL: Datenblatt des Quarzes
*CP+CI ca. 5pF

Am Beispiel von CL = 32pF:

C = 2x32pF-5pF = 59pF

C1 und C2 sind die vom Hersteller des Kontrollers empfohlenen Werte, mit ihnen wird die Schwingsicherheit der Oszillatorschaltung gewährleistet. C1 und C2 sollten in etwa eingehalten werden (so + - 20% machen aber nichts aus).

CL, der im Datenblatt angegebene Wert, wird beim Abgleich des Quarzes während der Herstellung benutzt.

Wenn CL nicht eingehalten wird, hat das keinen Einfluss auf das Schwingen des Oszillators (solange der Faktor2 nicht überschritten wird) sondern nur auf die Frequenz, aber das in einem Maße (max. 0,01%der Frequenz), das für die meisten Mikrokontrolleranwendungen bedeutungslos ist.
{{Warnung |
;Soll ein Uhrenquarz eine Real-Time-Clock versorgen, so sind die Kapazitäten von großer Wichtigkeit. Die Uhr läuft bei falsch dimensionierten Kapazitäten gleich im 3-Stelligen PPM-Bereich falsch. Das bedeutet praktisch gleich mehrere Minuten pro Tag!
}}

= Einstellung der Fuses =
{{Warnung |
;Hier ist besondere Vorsicht geboten. Fast immer liegt hier das Problem, wenn ein Mikrocontroller nicht mehr läuft!
}}
Ein Quarz ist '''keine''' "External Clock", sondern ein "External Crystal/Ceramic Resonator".
Wenn man wirklich auf Nummer sicher gehen will, sollte man:
*Das Datenblatt '''genau''' lesen (Abschnitt "Clock Source")
*Beim Fuse Calculator [http://www.engbedded.com/fusecalc] die Fuses berechnen lassen
*Nochmals genau überprüfen
Siehe auch: [[AVR_Fuses#Taktquellen_Fuse_Einstellung]]

= Siehe auch =
*AppNotes von Atmel zum Thema Quarze: [http://www.atmel.com/Images/doc2521.pdf][http://www.atmel.com/Images/doc8128.pdf]
*Fuse Calculator: [http://www.engbedded.com/fusecalc]

Vorlage:Warnung

2012-05-16T09:33:23Z

Cmf:

2012-05-15T19:23:30Z

Cmf:

Vorlage:Warnung

2012-05-15T19:22:40Z

Cmf:

<div style="min-height: 30px; margin:1em; padding:1em; border:solid 2px #ee0040;">
<div>
<div style="float:left; width:30px">[[Datei:Ausrufezeichen.png]]</div>
<div style="float:right; width: 90%">{{{1|}}}</div>
</div>
</div>

Vorlage:Warnung

2012-05-15T19:22:20Z

Cmf:

Vorlage:Warnung

2012-05-15T19:21:38Z

Cmf:

Vorlage:Warnung

2012-05-15T19:20:56Z

Cmf: Ausrufezeichen eingefügt

<div style="min-height: 30px; margin:1em; padding:1em; border:solid 2px #ee0040;">
<div>
<div style="float:left; width:10%">[[Datei:Ausrufezeichen.png]]</div>
<div style="float:right; width:10%">{{{1|}}}</div>
</div>
</div>

Datei:Ausrufezeichen.png

2012-05-15T19:14:11Z

Cmf: Selbst gezeichnet

Selbst gezeichnet

AVR Checkliste

2012-05-15T18:56:06Z

Cmf: /* Quarz oder Quarzoszillator angeschlossen? */

[[Category:AVR]]
Diese Seite soll als erste Anlaufstelle dienen, wenn der [[AVR]]-Mikrocontroller mal wieder nicht so will wie er soll. Es wird versucht, die Standardfehler und Probleme aufzulisten und zu erklären, was man dagegen tun kann.

== Hardware ==

=== Anderen Controller benutzt als den im Schaltplan: Pinkompatibilität sichergestellt? ===

Nur wenige AVR-Controller sind pinkompatibel und damit untereinander austauschbar. Manchmal liegen gar die am dringensten benötigten Funktionen (ISP-Programmierung) bei anderen Controllern auf anderen Pins. Unbedingt vorher die Belegungen anhand der Datenblätter vergleichen!

=== Fuses richtig gesetzt? ===

Die AVR-Controller haben 'Fuses' (deutsch: 'Sicherungen'), die das Verhalten des Prozessors auf grundlegender Ebene bestimmen. Ein häufiger Fehler ist beispielsweise, dass die falsche Taktquelle gewählt wurde (Fuse "CKSEL" etc.): einige AVRs können mit dem internen Oszillator (<i>internal R/C</i>), mit einem externen Oszillator (<i>external clock</i>), mit einem Quarz (<i>external crystal</i>) oder mit einem Resonator (<i>external R/C</i>) betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu passt (z. B. <i>external clock</i> statt <i>external crystal</i>), fehlt dem Controller unter Umständen der Systemtakt und er läuft nicht an, oder man bekommt auf der seriellen Schnittstelle Nonsens, oder die Timer bzw. Zeitschleifen im Programm laufen zu langsam oder zu schnell.

Eine andere Fuse (JTAGEN) schaltet auf einem Port (z. B. PORTC auf ATMega32) die JTAG-Unterstützung ein bzw. aus. Wenn sie eingeschaltet ist, funktionieren vier Bits dieses Ports nicht wie gewohnt, da sie für die JTAG-Schnittstelle reserviert werden.

In dem zum STK500 gehörenden Entwicklungstool 'AVR Studio' gibt es in der Programmer-Dialogbox einen Tab 'Fuses', der controllerabhängig den Status der Fusebits anzeigt und Änderungen ermöglicht.
Siehe auch: [[AVR Fuses]].

=== ISP-Adapter ===

Bei ISP-Programmieradaptern für den Parallelport kann es zu Inkompatibilitäten mit manchen Ports kommen. Tritt das Problem auch auf, wenn der ISP-Adapter an einem anderen Rechner angeschlossen ist? Funktioniert es vielleicht mit einer anderen Software? Siehe auch: [[AVR In System Programmer]]).

Bei seriellem Programmer mit Controller (STK500, Atmel AVRISP etc.): Programmieren dauert sehr lange, es gibt Fehler. Abhilfe: ISP Taktrate richtig einstellen (<1/4 F_CPU).

Beim Programmieren mit dem usbasp Programmieradapter muss die Geschwindigkeit richtig eingestellt werden. Bei einem AVR der auf den eingebauten 1 Mhz läuft muss mit langsamer Geschwindigkeit (Jumper zu) programmiert werden.

=== Programmieren via SPI und angeschlossene SPI-Hardware ===
Wenn Peripherie über SPI angebunden ist, muss sich diese zum Programmierzeitpunkt auf dem Bus neutral verhalten. Normalerweise bedeutet dies, dass die Slave-Select/Chip-Select-Leitungen der Peripherie auf high gezogen werden müssen, wenn die Chips keinen internen Pull-Up haben. Werte von 10 kΩ bis 100 kΩ für normale Anwendungen haben sich bewährt.

=== Spannungsversorgung richtig angeschlossen? ===

Der AVCC-Pin ist der Versorgungsanschluss für den AD-Wandler und den zugehörigen Port. Er ist nicht an allen AVRs vorhanden; wenn er aber vorhanden ist, so muss er auf jeden Fall angeschlossen sein, auch wenn der AD-Wandler nicht benutzt wird. Wird der AD-Wandler verwendet, sollte zur Verbesserung der Genauigkeit der AVCC-Pin über einen Lowpass-Filter angeschlossen werden (siehe Datenblatt).
Oft funktioniert die Programmierung des Controllers auch, wenn Vcc oder GND nicht richtig angeschlossen ist. Zur Sicherheit kann man mit einem Messgerät direkt an den Anschlüssen des AVRs kontrollieren (VCC-GND, AVCC-GND) prüfen, ob die Verbindungen korrekt sind. Es empfiehlt sich, vor dem Einsetzen bzw. Einlöten des Controllers die Versorgungsanschlüsse nochmals zu prüfen, um sicherzustellen, dass man den IC nicht durch eine zu hohe Spannung aufgrund eines Fehlers in der Versorgung zerstört.

=== Reset-Pin korrekt beschaltet? ===

Der Reset-Anschluss am AVR ist 'active-low', d. h. wenn man den Pin mit GND (Masse) verbindet, wird der Controller zurückgesetzt gehalten. Zwar haben die meisten(!) AVRs einen internen Pullup-Widerstand, der den Reset-Pin gegen VCC "zieht", dieser ist jedoch relativ hochohmig (ca. 50 kΩ, vgl. Datenblatt) und reicht in extrem stark gestörter Umgebung nicht aus, um den Reset-Pin sicher "hochzuhalten". Als Mindestbeschaltung empfiehlt sich dringend, einen externen Pullup-Widerstand vorzusehen (typisch 10 kΩ), der den Reset-Pin mit VCC verbindet. Er sollte nicht kleiner als 4,7 kΩ sein, da der Programmieradapter sonst eventuell den Reset-Pin während des Programmiervorgangs nicht sicher auf "low" ziehen kann. Mit einem Oszilloskop kann man gut überprüfen, ob der Pegel am Reset-Pin sauber zwischen high und low wechselt. Zusätzlich sollte man auch noch einen Kondensator 47 nF oder 100 nF zwischen Reset-Pin und GND anordnen. Dieses RC-Glied sorgt dafür, dass der Controller beim Einschalten der Versorgungsspannung für eine definierte Zeitspanne im Reset gehalten wird. Im laufenden Betrieb sorgt der Kondensator dafür, dass der Reseteingang unempfindlich gegenüber Spikes und Glitches wird. Er sollte deshalb unmittelbar in Pin-Nähe beim Prozessor untergebracht werden. Dieser Kondensator darf jedoch nicht verwendet werden, wenn [[debugWIRE]] möglich sein soll.

Atmel empfiehlt zusätzlich noch zum Schutz vor Überspannungen eine externe Diode nach VCC ("Clamp-Diode"), da für den Reset-Pin keine interne vorhanden ist. Diese Diode bereitet jedoch bei manchen Programmieradaptern Schwierigkeiten. Allerdings schützt die Diode den Controller davor, in den High-Voltage Programming Mode zu schalten, zum Beispiel als Folge von Störspannung wegen EMV, und dadurch den Programmspeicher zu überschreiben.

=== Flashen / Lesen / Fuse nur ein mal möglich ===

Es kann vorkommen das ein AVR nur ein mal programmiert werden kann, danach geht es nicht mehr (z.B. Typ wird nicht mehr erkannt). Erst nachdem die Versorgungsspannung getrennt / wider verbunden ist geht es erneut.

In diesem Fall ist meistens der Resetpin kurzgeschlossen, daher lässt sich der AVR ein mal programmieren.

Der Reset PIN müsste bei korrekter Beschaltung eine Spannung nahe VCC (z.B. 4.9V) aufweisen, ist die Spannung bei GND ist der Pin kurzgeschlossen, und verursacht dieses Problem.

=== Abblockkondensator(en) ordnungsgemäß installiert? ===

Abblockkondensatoren ("Bunker-Kondensatoren") dienen dazu, sehr kurze Versorgungsspannungseinbrüche, die durch Schaltvorgänge verursacht werden können, zu kompensieren. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden:

* Ein Abblockkondensator sollte möglichst dicht am IC sitzen.

* Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen.

* Bei ICs mit mehreren Anschlüssen für VCC und GND sollte jedes VCC-GND-Paar mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren).

* Es sollten keramische Kondensatoren mit einer Kapazität von 100 nF verwendet werden. Größere Kondensatoren, etwa 10 µF-Elkos, sind für diese Aufgabe ''nicht'' geeignet, weil sie "zu langsam" sind!

=== Quarz oder Quarzoszillator angeschlossen? ===

Die neueren AVRs haben einen internen [[Oszillator]], der im Auslieferungszustand über die entsprechenden Fuses eingeschaltet ist. In diesem Fall muss kein externer [[Quarze und AVR|Quarz]] mehr angeschlossen werden. Man kann in den [[AVR Fuses|Fuse-Bits]] aber einstellen, dass man einen externen Taktgenerator (''external clock'', z. B. Quarzoszillator) oder externen Quarz (''external crystal'') verwenden möchte.

Dann, oder wenn der AVR keinen internen Takt hat, wird an die entsprechenden Pins des Controllers ein Quarz (''external crystal'', Bauelement mit zwei "Beinchen") oder Quarzoszillator (''external clock'', Bauelement mit vier "Beinchen") angeschlossen. Im Falle eines Quarzes werden die XTAL-Pins mit den beiden Anschlüssen des Quarzes und jeweils mit einem Kondensator (ca. 12 bis 22 pF) (vgl. Datenblatt ATMega 8) gegen Masse angeschlossen. Im Falle eines Quarzoszillators reicht es aus, den Taktausgang mit dem XTAL1-Pin zu verbinden, und den XTAL2-Pin unbeschaltet zu lassen. Die Fuses sind entsprechend einzustellen.

=== Alle Ground-Anschlüsse beschaltet? ===

Bei AVRs mit mehreren Ground-Anschlüssen müssen alle Anschlüsse beschaltet werden. Siehe http://www.mikrocontroller.net/forum/read-1-107259.html

=== Alle Lötstellen in Ordnung? ===

"Kalte", d.h. schlechte Lötstellen erkennt man an ihrer matten Oberfläche (bei bleihaltigem Lot). Bei beschädigten Lötstellen erkennt man oft einen Riss, der sich kreisförmig um die Mitte des Lötpunktes herum gebildet hat. Solche Stellen verursachen oft erst bei mechanischer Beanspruchung Probleme.

Bei kleinen Abständen (SMD-Bauteile) müssen besonders Verbindungen zwischen benachbarten Lötungen kontrolliert werden.

Bei Lochrasterplatinen kann man mit einem spitzen Messer (Bastelmesser) die Zwischenräume von möglichen leitenden Verbindungen befreien.

=== Eingänge ===

Taster müssen:

* entprellt werden ([[Entprellung]])

* einen [[AVR-GCC-Tutorial#Tasten_und_Schalter|Pullup-Widerstand]] besitzen, so sie ''active-low'' betrieben werden, d.h. wenn beim Tastendruck der Pin mit GND (Masse) verbunden wird (dies ist die übliche Anschaltung). Man kann einen externen Pull-Up Widerstand (typ. 10 kOhm) benutzen oder den internen aktivieren (DDR als Eingang also "0", PORT auf "1").

Will man einen Taster ''active-high'' betreiben, soll also bei Tastendruck eine "1" in PIN gelesen werden, ist ein externer Pull-Down-Widerstand (typ. 10 kOhm) gegen GND anzuschließen, denn interne Pull-Downs sind nicht verfügbar.

Symptome: Aufgrund des Prellens bekommt man bei einem Tastendruck statt eines Signals mehrere, und beim fehlenden Pullup fängt man sich Störungen (z. B. das 50 Hz-Netzbrummen) ein, da der Pin nicht auf einem "definierten Pegel" liegt, wenn der Taster nicht geschlossen ist. Soll z. B. bei einem Tastendruck eine LED angehen, dann leuchtet die LED durch das Netzbrummen plötzlich mit 50 Hz anstatt aus zu sein.

* active low: ein Anschluss des Tasters an den Port-Pin, den anderen Taster-Anschluss an GND; internen Pull-Up-Widerstand aktivieren oder externen Widerstand zwischen Port-Pin und VCC.

* active high: Taster zwischen Port-Pin und VCC; externen Widerstand zwischen Port-Pin und GND.

=== Ausgänge ===

Man sollte darauf achten, das "kritische" Ausgänge, d.h. Ausgänge, über die nicht "nur" eine LED geschaltet wird, einen definierten Zustand haben, wenn der Portpin auf "Eingang" und damit hochohmig geschaltet ist. Dadurch wird sichergestellt, dass beim Einschalten nicht kurz ein Verbraucher geschaltet wird (z. B. "Zucken" eines Motors). Dies kann man bewerkstelligen, indem man extern Widerstände (auch hier Pull-Up bzw. Pull-Down genannt, typ. 10 kOhm) an den Ausgangs-Pins vorsieht, die den Ausgang auf den gewünschten Zustand ziehen.

=== Besonderheiten bei ATmega128 und seinen Derivaten im 64-Pin-Gehäuse===

[[Bild:isp.png|thumb|300px|right|ISP-Adapter]]
Der ATmega64 und der ATmega128 sowie alle vom ATMega128 abgeleiteten AVRs im 64-Pin-Gehäuse (ATMega641/1281/2561 sowie AT90CAN32/64/128, Ausnahmen sind nur AT90USB64/128, die eine ganz andere Pinbelegung haben) haben besondere Fallstricke, über die man bei nicht ausreichendem Datenblattstudium leicht stolpert.

* Der erste betrifft den Anschluss der ISP-Signale (MISO, MOSI, SCK, RESET). Dieser erfolgt nicht wie bei den meisten anderen AVR-Controllern an den gleichnamigen Pins, sondern an PDI, PDO, SCK und RESET. Die Pinzuordnung ist:
:* MOSI → PE0 (Pin 2)
:* MISO → PE1 (Pin 3)
:* SCK → PB1 (Pin 11)
:* RESET → RESET (Pin 20)
: PEN (Pin 1) hat für normale ISP-Adapter keine Bedeutung und kann offen gelassen oder direkt mit Vcc verbunden werden. Die Benutzung der Pins PDI und PDO anstelle von MOSI und MISO gilt für praktisch alle ATmega128-Derivate im 64-Pin-TQFP-Gehäuse, darunter AT90CAN32/64/128 und ATmega641/1281/2561. Im Zweifelsfall im Datenblatt (Pin Configuration) nachsehen, ob PE0 und PE1 mit "PDI" bzw. "PDO" beschriftet sind.

* Die zweite kleine Gemeinheit betrifft die M103C-Fuse (ATmega103 Compatibility Mode, nur bei den ATmega-Typen, nicht beim AT90CAN32/64/128). Diese ist bei fabrikneuen Atmega64/128 gesetzt und sorgt dafür, dass sich diese wie ein Atmega103 verhalten.
** Dies hat zur Folge, dass ein für den ATmega64 oder ATmega128 geschriebenes Programm beim ersten RET abstürzt, da der SRAM an einer anderen Stelle endet als erwartet und somit der Prozessor keine gültige Rücksprungadresse vom Stack holen kann.
** Außerdem funktionieren einige IO-Pins an PORTC, PORTF und PORTG anders.
** Für weitere Infos bzgl. [[TWI]], [[UART]], [[Timer]], [[Bootloader]] und Kalibrierung des internen RC-Oszillators unbedingt das Datenblatt lesen.

== Software ==

=== Alle Interruptvektoren definiert? ===

Wenn man irgendwelche [[Interrupt]]vektoren verwendet, sollte man alle definieren, auch die nicht benutzten. Passiert es dann aufgrund eines Fehlers, dass ein Interrupt unbeabsichtigt ausgeführt wird, so führt der Controller dann eine definierte Aktion aus. Benutzt man eine Hochsprache wie C oder Basic, nimmt einem der Compiler diese Arbeit ab.

Ausserdem sollte man immer im Datenblatt des Controllers nachsehen, wie die Interrupttabelle aufgebaut ist. Die kleinen AVRs verwenden ein RCALL zum Anspringen der Interrupts, welches 1 Wort lang ist. Die grossen AVRs mit mehr als 8 KiBi FLASH verwenden ein CALL, welches 2 Worte lang ist. Verwendet man nun den falschen Befehl, verschieben sich die Einsprungadressen und das Chaos ist perfekt.

In einem komplett interruptlosen Programm kann man auf die Interrupttabelle selbstverständlich verzichten (erkennbar daran, dass nirgendwo im Code Interrupts mittels Assembler-Befehl SEI eingeschaltet werden).

Oft hilft es einen Catch All Interruptvektor zu definieren um herauszufinden ob ein Fehler (z.B. ein Neubeginn des Programms) vorliegt.
<c>#include <avr/interrupt.h>

ISR (BADISR_vect)
{
// Hier eine Fehlerausgabe definieren.
// Z.B. UART-Ausgabe oder ein PIN toggeln
}</c>

Dann findet man solche Fehler recht schnell.

=== Alle Konfigurationsregister korrekt initialisiert? ===

Alle benötigten Konfigurationsregister (auch "I/O-Register" genannt) eines Mikrocontrollers müssen korrekt initialisiert werden. Bei Fehlfunktionen sollten diese Konfigurationen noch einmal mit dem Datenblatt abgeglichen werden.
Manchmal ist es auch sinnvoll, bestimmte Funktionen explizit abzuwählen. Ein Beispiel hierfür ist der [[Analog-Komparator]] des AVR: Schaltet man diesen ab, wenn man ihn nicht benötigt, kann man dadurch ein wenig Strom sparen.
Wenn man besonders "sauber" programmieren möchte, initialisiert man Konfigurationsregister immer, d.h. auch wenn sie nicht im Programm verwendet werden. Dies verhindert mögliche zufällige Fehlkonfigurationen.

=== Stackpointer initialisiert? (Nur in Assembler relevant) ===

Fehlerbeschreibung: ''Das Programm lief, bis ein "rcall" oder ein Interrupt eingefügt wurde. Danach ging plötzlich gar nichts mehr.''

Wahrscheinliche Ursache: Der Stack ist ein spezieller Bereich im RAM, der von Sprungbefehlen und Interruptaufrufen dazu verwendet wird, die Rücksprungadresse ins Hauptprogramm zu speichern. Da der Stack bei den AVRs nach "unten" wächst, d.h. in Richtung Anfang des RAMs, wird er üblicherweise ans Ende des RAMs gelegt. Der Stack muss vor der ersten Benutzung, am besten direkt am Anfang des Programms, initialisiert werden (sonst ist nach einem Sprung in ein Unterprogramm die Rücksprungadresse undefiniert und das Programm wird an einer unvorhersehbaren Stelle weiter ausgeführt, was in der Regel einen Absturz zur Folge hat). "Den Stack initialisieren" bedeutet, den Stackpointer auf den gewünschten "Startwert" zu setzen. Meistens wird dafür die letzte RAM-Adresse gewählt.

Die Initialisierung unterscheidet sich geringfügig je nach verwendetem AVR. Bei den alten AT90xxxx und den ATtinys ist sie mit zwei Zeilen erledigt:

<avrasm>
ldi r16, RAMEND ;Die Adresse der letzten Stelle im RAM in r16 laden
out SPL, r16 ;Die Adresse in das Register SPL ausgeben
</avrasm>

Da die ATmegas mehr RAM haben, reicht das 8 bit-Register SPL nicht mehr, und es ist ein zweites (SPH) dazugekommen. Die Initialisierung des Stacks erfordert hier vier Zeilen:

<avrasm>
ldi r16, LOW(RAMEND) ;Untere 8 bit des 16 bit-Wertes RAMEND laden
out SPL, r16
ldi r16, HIGH(RAMEND) ;Obere 8 bit laden
out SPH, r16
</avrasm>

=== 16bit-Register in richtiger Reihenfolge geladen/gelesen? (Nur in Assembler relevant) ===

Bei den 16-bit Registern (z. B. Timer1) genau die Hinweise im Kapitel "Accessing 16-bit Registers" beachten!

So muss z. B. das High-Byte VOR dem Low-Byte geschrieben werden, weil mit dem Schreiben des Low Byte das gesamte Register "übernommen" wird.
Beim Lesen muss zuerst das Low-Byte gelesen werden, dann das High-Byte.
Es wird dadurch garantiert, dass sich zwischen den beiden einzelnen Befehlen nicht noch das Register weiter verändert, z. B. beim 16bit Counter.
Möglich wird das durch ein "temporary Register", von dem es aber nur eines gibt - was beachtet werden muss, da zwischen diesen beiden einzelnen Lese-/Schreib-Befehlen kein Interrupt auftreten darf, der selber das temporary Rgegister benutzt.

In C oder Basic kümmert sich der Compiler um das Problem - man liest oder beschreibt dann einfach z. B. TCNT1 anstatt TCNT1H und TCNT1L einzeln.

=== Flag richtig gelöscht? ===

Ein beliebter Fehler ist, dass man überliest, dass gesetzte Flags (z. B. die Interrupt-Flags) durch beschreiben mit einer '1' und nicht mit einer '0' gelöscht werden!

Beispiel:
* das Flag ist zuerst '0'
* das Ereignis (z. B. Zählerüberlauf, also Bit TOV0 in TIFR) tritt auf und setzt das jeweilige Bit im Register auf '1'
* wir haben auf die '1' gewartet und wollen das Bit nun wieder löschen und müssen dafür eine '1' (eins!) in das Register schreiben, '''keine''' '0'. Trotzdem wird das Bit dadurch '0' z. B.:
<c>
TIFR = (1<<TOV0);
</c>

Das ganze ist kein Fehler, sondern hat seine guten Gründe.

Wenn Interrupts zugelassen sind (z. B. in TIMSK) und die Interruptroutine aufgerufen wird, werden diese Flags zumeist automatisch gelöscht.

Der UART-Empfangs-Interrupt (RXC in UCSRA) jedoch nicht! Der wird gelöscht durch Auslesen des Empfangsregisters (UDR). Hier liegt wiederum ein beliebter Stolperstein: Man prüft oft zuerst in der Interruptroutine die Fehlerflags (z. B. Parity) und macht dann manchmal den Fehler das empfangene Zeichen im Fehlerfall nicht auszulesen. Das führt dann zum Absturz (der IRQ wird immer wieder aufgerufen) - man muss also immer das UDR lesen auch wenn etwas Fehlerhaftes drinsteht.

Zusätzlich ist zu beachten, dass in C die Interrupt-Flags '''nicht''' mit einer Veroderung des Registers (z. B. TIFR |= (1 << TOV0)) gelöscht werden sollten, da bei dieser Operation alle anderen evtl. gesetzten Flags im betreffenden Register ebenfalls gelöscht werden. Es ist die Schreibweise von oben zu benutzen (also TIFR = (1 << TOV0))!

=== Alle Interrupt Variablen als volatile bezeichnet? ===

Das Schlüsselwort volatile kann als Attribut an Variablen gehängt werden. Der Ausdruck „volatile int i“ versieht die Integervariable i mit dem Attribut volatile. Das Attribut weist den Compiler an, diese Variable nicht zu optimieren, sondern im Speicher abzulegen und zu beachten, dass diese Variable von anderen Prozessen geändert werden kann. Normale Variablen können durch den Compiler auf Register reduziert werden, oder die Daten werden einmalig aus dem Speicher geladen und erst am Ende des Programmes wieder zurückgeschrieben. Das kann Probleme bereiten, wenn beispielsweise in einer [[Interrupt]]routine die Variable verändert wird. Darum müssen alle globalen Variablen, die in einer Interruptroutine geändert werden, mit diesem Schlüsselwort versehen werden.

=== Die Programmierfrequenz passend? ===

Sollte ein Programmieren nicht möglich sein erst einmal die Programmiergeschwindigkeit bei AVR dude mit der Option
-B bitclock anpassen
wobei bitclock die Perioden dauer in Milisekunden (floating-point Zahl) ist. Normalerweise -B 1 für Controller mit >=4MHz daher ist bei der Erstprogrammierung ein höherer Wert zu versuchen.

== Serielle Verbindungen ==

=== [[I²C]]/[[TWI]] ===

Sind die Leitungen SCL und SDA mit einem Pullup-Widerstand ausgestattet? Die I²C-Bus-Leitungen SCL und SDA müssen über einen Pullup-Widerstand mit einem Wert von 4,7 kΩ bis 10 kΩ mit der Versorgungsspannung (+5 V) verbunden sein.

=== UART/USART ===

==== Übertragungsprobleme durch falschen oder ungenauen Takt ====

* Der interne [[Oszillator]] ist recht ungenau und nicht temperaturstabil. Daher kann die Umgebungstemperatur auch den [[UART|USART]]-Takt verändern. Für serielle, asynchrone Kommunikation per UART sollte man deshalb immer einen Quarz oder einen Oszillator verwenden, egal bei welcher Baudrate: 3% Fehler sind immer 3% Fehler, egal ob bei 1200 oder 9600 [[Baud]]. Falls doch der interne Oszillator verwendet wird: Wurde er für die richtige Frequenz und Betriebsspannung kalibriert?

* Nicht mit allen Quarzen kann man alle Baudraten genau genug erzeugen. Deswegen gibt es [[Baudratenquarz]]e wie z. B. 3,6864 MHz. Näheres steht im Datenblatt.

* Geschieht die Konfiguration des U(S)ART automatisch durch die Programmiersprache (z. B. in [[Bascom AVR|BASCOM]], [[C]]), dann muss dort der Takt ''genau'' angegeben werden. Setzt man z. B. einen 3,6864 MHz-Quarz ein, darf man dort nicht einfach "4 MHz" angeben, weil dann die Abweichung mit ca. 8% viel zu hoch wäre. Damit funktioniert die Übertragung nicht mehr.

* Im AVR-Studio kann man die Taktfrequenz sowohl über ein <code>#define F_CPU</code> im Quelltext als auch über das Optionsmenu oder das selbsterstellte Makefile einstellen. Es darf nur ''eine'' Variante verwendet werden!

* Wenn ein externer Oszillator oder Quarz angeschlossen ist: Sind die [[AVR Fuses | Fuses]] des Controllers so gesetzt, dass er auch verwendet wird?

* Ist die Fuse CLKDIV ''nicht'' programmiert?

* Es taucht auch des öfteren das Missverständnis auf, dass man nur F_CPU verändern muss, um den µC mit einem anderen Takt laufen zu lassen. Dem ist nicht so. Der µC-Takt wird durch die Fuses bzw. den eventuell angeschlossenen Quarz oder Quarzoszillator bestimmt. F_CPU dient nur dazu, die dadurch festgelegte Frequenz im C-Programm zur Verfügung zu haben. F_CPU ist nur eine Information, mit der man bei der Programmierung arbeiten kann. Aber ein anderer F_CPU-Wert führt nicht dazu, dass der µC dann magisch auf diese Frequenz umgestellt wird.

* Um zu prüfen, ob der externe Quarz auch wirklich verwendet wird, kann man mittels _delay_ms() testweise eine LED im Sekundentakt blinken lassen. Den Unterschied zwischen Quarz und internem RC-Oszillator kann man bei grösseren Frequenzunterschieden leicht sehen. Ebenso sieht man, ob versehentlich die CLKDIV Fuse gesetzt ist: die Blinkfrequenz ist dann achtmal langsamer. Allerdings muss man auch hier aufpassen. Siehe [[AVR-GCC-Tutorial#Warteschleifen (delay.h)|AVR-GCC-Tutorial: Warteschleifen]].

Im folgenden Programm muss angepasst werden:
*Die vermeintliche Taktfrequenz F_CPU
*der Port und der Pin, an dem eine LED angeschlossen ist.

Wird das Programm laufen gelassen, muss die LED 1 Sekunde ein/1 Sekunde aus sein. Stimmen die Zeiten nicht, ist das ein deutlicher Hinweis darauf, dass die tatsächlich vom µC verwendete Taktfrequenz nicht mit der in F_CPU angegebenen übereinstimmt. Das Programm muss mit aktivierter Optimierung <code>-Os</code> compiliert werden.
<c>
// Testprogramm für CPU Takt
// Hier die vermeintliche Taktrate des µC eintragen
// Im Beispiel hier: 1Mhz

#define F_CPU 1000000

#include <avr/io.h>
#include <util/delay.h>

// Hier die tatsächlich verwendeten Parameter angeben

#define LED_PORT PORTB
#define LED_DDR DDRB
#define LED_PIN PB0

int main()
{
LED_DDR |= 1 << LED_PIN;

while (1)
{
LED_PORT ^= 1 << LED_PIN;
_delay_ms(1000);
}

return 0;
}
</c>

* Erscheinen im Terminalprogramm kryptische Zeichen anstatt ordentlichen Buchstaben (z. B. ü statt A), liegt das zu 99,9% an einer falsch eingestellten/erzeugten Baudrate im Mikrocontroller. Meistens wiederum liegt dies daran, dass der µC nicht mit der vermeintlichen Taktrate läuft und daher die Baudratenparameter falsch berechnet werden.

* URSEL-Bit in UCSRC: Bei der Initialisierung der UART beachtet, wenn das für den verwendeten AVR notwendig ist, siehe [[AVR-GCC-Tutorial/Der_UART#Die_UART-Register|AVR-GCC-Tutorial/Der UART: Die UART-Register]].

* In den Tutorials für [[AVR-Tutorial: UART |Assembler]] und [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Der_UART GCC] wird die Nutzung recht gut erklärt und mit Beispielen erläutert.

==== Sonstige Fehlerquellen bei UART/USART ====

* Funktioniert die Datenübertragung zum PC nur solange der Programmieradapter eingesteckt ist, deutet dies auf ein Problem mit der Masse hin (z. B. GND-Anschluss am RS232-Stecker nicht belegt oder dergleichen).

* Der Pegelwandler/Inverter (z. B. MAX232) muss mit Kondensatoren für die internen Ladungspumpen beschaltet werden. Beim MAX232 sind dies mindestens vier Kondensatoren ≥ 1 µF (Polung beachten!), beim MAX202, MAX232A und MAX3232 vier Kondensatoren ≥ 100 nF. Hinzu kommt der obligatorische Abblockkondensator von 100 nF keramisch zwischen VCC und GND des ICs. Das jeweilige Datenblatt gibt Auskunft über die Beschaltung bei "typischer Anwendung".

* TX/RX vertauscht? Modem- oder Nullmodemkabel?

* Bei Kommunikation mit PC: ist die serielle Schnittstelle richtig konfiguriert? Nicht nur Baudrate, Stopp- und Parity-Bits, sondern auch Handshakeverhalten muss stimmen (kein Hardwarehandshake bei ausschließlicher Verwendung der Pins RX/TX).

* Wird das Signal eventuell durch zusätzliche Chips invertiert? (EEPROM von FT232 falsch Programmiert)

* Die Hardware und Verkabelung kann man schnell prüfen, indem man den Pin R1OUT bzw. R2OUT mit T1IN bzw. T2IN am MAX232 miteinander verbindet (je nachdem welches Pinpaar verwendet wird). Dann sollte man auf dem PC ein Terminalprogramm wie Hyperterminal starten und nach dem Eingeben von Zeichen diese sofort angezeigt bekommen, egal mit welcher Baudrate. Lediglich die Flusssteuerung muss auf "Kein" eingestellt werden.

: Man muss aber beachten, dass T1IN bzw. T2IN für diesen Test ''nicht'' mit dem Mikrocontroller verbunden sein darf, weil sonst zwei Ausgänge miteinander verbunden sind, siehe [[Ausgangsstufen Logik-ICs]]. Wenn der µC gesockelt ist, kann man ihn dafür einfach aus dem Sockel nehmen und die RX/TX Pins direkt im µC-Sockel mit einem Stück Draht verbinden.

* UART Ausgabe-Pin als Output-Pin deklariert?

* Spannung an Pin 15 und 16 liegt an? (Falsche Zeichen kommen an, aber in der richtigen Reihenfolge. Beim Test durch Kurzschluss von T1IN und R1OUT kommt nichts an)

=== SPI (Hardware) ===
* Master Mode: SS Pin als Ausgang oder auf High gelegt? (siehe hier: [http://www.holger-klabunde.de/avr/avrhelp.htm] )
* SPI zu schnell
* Hängen andere SPI-Devices am Bus, die undefiniertes CS haben?
* Sind die DDR-Register der SPI-Ports richtig gesetzt?

== Analog-Digital-Wandler ==

* Sind die Pullup-Widerstände deaktiviert? (im allgemeinen)
* (im speziellen) Bei einige Controllern liegt der JTAG mit auf den ADC-Pins. Die betroffenen ADC-Kanäle werden erst richtig funktionieren, wenn der JTAG deaktiviert ist. Das geht per Fuse oder - wenn man an die Fuses nicht mehr herrankommen sollte, weil man mit einem Bootloader arbeitet - auch per Software.

== Weblinks ==
* [http://www.atmel.com/dyn/resources/prod_documents/doc2521.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]

Quarze und AVR

2012-05-15T18:55:03Z

Cmf: /* Einstellung der Fuses */

Diese Seite behandelt Quarze im Zusammenhang mit AVRs. Für allgemeine Informationen zum Thema siehe [[Quarz]].

Die Genauigkeit von Quarzen liegt bei 10-100ppm (1ppm = 0,0001 %) und wird somit nur noch vom [[Quarzoszillator]] überboten. Außerdem sind Quarze im Gegensatz zum internen RC-Oszillator weniger temperaturunabhängig.

= Verwendung =
Quarze sind in folgenden Situationen sinnvoll / notwendig:

* Interner Oszillator des µC zu langsam
* Interner Oszillator des µC zu ungenau
**Bei Verwendung des [[UART]]
**Bei zeitkritischen Anwendungen wie z.B. einer Uhr

= Wahl der richtigen Frequenz =
Vor allem als Anfänger denkt man sich, ''ich kaufe einfach mal 10MHz, das ist eine so schön gerade Zahl''. Allerdings sind diese Quarze nur in den seltensten Fällen sinnvoll. Viel sinnvoller sind [[Baudratenquarz]]e. "Baudraten"-Frequenzen sind ganzzahlige Vielfache der bei RS232 üblichen Baudraten. Mit Baudrate-Frequenz kann man exakte Baudraten erreichen, mit "runden" Frequenzen entstehen Fehler, weshalb oft nur sehr niedrige Baudraten möglich sind.

"Runde" Frequenzen (4MHz, 8MHz, 10MHz....) sind meist leichter erhältlich und haben den Vorteil, dass man Verzögerungsschleifen und Rechendauern relativ leicht errechnen kann.

= Anschluss =
[[Bild:Quarz_Anschluss_AVR.png|right|framed]]
Die Kapazitäten von C1 und C2 entsprechen '''nicht''' der Lastkapazität des Quarzes!
Sie errechnen sich folgendermaßen:

C=2xCL-(CP+CI)

*CP: Leiterbahnen bedingte Kapazität
*CI: Portbedingte Kapazität
*CL: Datenblatt des Quarzes
*CP+CI ca. 5pF

Am Beispiel von CL = 32pF:

C = 2x32pF-5pF = 59pF

C1 und C2 sind die vom Hersteller des Kontrollers empfohlenen Werte, mit ihnen wird die Schwingsicherheit der Oszillatorschaltung gewährleistet. C1 und C2 sollten in etwa eingehalten werden (so + - 20% machen aber nichts aus).

CL, der im Datenblatt angegebene Wert, wird beim Abgleich des Quarzes während der Herstellung benutzt.

Wenn CL nicht eingehalten wird, hat das keinen Einfluss auf das Schwingen des Oszillators (solange der Faktor2 nicht überschritten wird) sondern nur auf die Frequenz, aber das in einem Maße (max. 0,01%der Frequenz), das für die meisten Mikrokontrolleranwendungen bedeutungslos ist.

= Einstellung der Fuses =
{{Warnung |
;Hier ist besondere Vorsicht geboten. Fast immer liegt hier das Problem, wenn ein Mikrocontroller nicht mehr läuft!
}}
Ein Quarz ist '''keine''' "External Clock", sondern ein "External Crystal/Ceramic Resonator".
Wenn man wirklich auf Nummer sicher gehen will, sollte man:
*Das Datenblatt '''genau''' lesen (Abschnitt "Clock Source")
*Beim Fuse Calculator [http://www.engbedded.com/fusecalc] die Fuses berechnen lassen
*Nochmals genau überprüfen
Siehe auch: [[AVR_Fuses#Taktquellen_Fuse_Einstellung]]

= Siehe auch =
*AppNotes von Atmel zum Thema Quarze: [http://www.atmel.com/Images/doc2521.pdf][http://www.atmel.com/Images/doc8128.pdf]
*Fuse Calculator: [http://www.engbedded.com/fusecalc]