Mikrocontroller.net - Benutzerbeiträge [de]

AVR Checkliste

2015-06-09T08:36:06Z

80.64.189.58:

[[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 dringendsten 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 (internal R/C), mit einem externen Oszillator (external clock), mit einem Quarz (external crystal) oder mit einem Resonator (external R/C) betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu passt (z. B. external clock statt external crystal), 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 einmal möglich ===

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

In diesem Fall ist meistens der Resetpin kurzgeschlossen, daher lässt sich der AVR einmal 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 dienen dazu, impulsartige Einbrüche der Betriebsspannung, die durch schnelle Schaltvorgänge verursacht werden können, zu minimieren. Sie verhindern unkontrollierte Brownouts, welche durch diese Spannungseinbrüche auftreten können. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden:

* Ein Abblockkondensator sollte möglichst dicht am IC sitzen.
* Eine niederimpedante Anbindung sollte gegeben sein - also keine Stegleitungen. Dies bedeutet, das die Versorgungsspannung erst durch das Pad des Abblockkondensators fließen MUSS und dann weiter zum IC gereicht wird

* Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen.

* Bei ICs mit mehreren Anschlüssen für VCC sollte jeder VCC-Pin mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren). Dabei ist darauf zu achten, jeder Abblockkondensator mit einem eigenen Via auf die niederimpedante (heißt Hochfrequenz gut leiten) großflächige, nicht unterbrochene Massefläche kontaktiert wird.

* Es sollten keramische Kondensatoren mit einer Kapazität von maximal 100 nF verwendet werden. Größere Kondensatoren, etwa 10 µF-Elkos, sind für diese Aufgabe ''nicht'' geeignet, weil sie "zu langsam" sind (der Widerstand=Impedanz ist bei hochfrequenten Spannungen zu groß - ein schneller (hochfrequenter) Spannungsimpuls kann so nicht abgeleitet werden)!

=== 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 ICs mit mehreren Ground-Anschlüssen müssen immer 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, dass "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, AT90PWM2/3/2B/3B 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 ==

=== Mainschleife vorhanden? ===

Insbesondere beim Testen von Interrupts kann es passieren, dass man keine eigentliche Programmschleife vorsieht, weil ja alles in den Interrupts passiert. Das führt dazu, dass der Controller nach Abarbeiten aller Befehle in <syntaxhighlight lang="c">int main(void) {}</syntaxhighlight> seine Arbeit einstellt und daher auch keine Interrupts mehr funktionieren. Demnach sollte bei rein Interrupt-basierten Programmen die Funktion mindestens so aussehen:
<syntaxhighlight lang="c">int main(void)
{
// hier Interrupts definieren
// und einschalten
while (1){}
}</syntaxhighlight>

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

Außerdem 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.
<syntaxhighlight lang="c">#include <avr/interrupt.h>

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

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:

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

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:

<syntaxhighlight lang="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
</syntaxhighlight>

=== 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.:
<syntaxhighlight lang="c">
TIFR = (1<<TOV0);
</syntaxhighlight>

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.

=== Wo nötig Variablenzugriff atomar gestaltet? ===
Der Zugriff auf Variablen >8 Bit welche in der ISR und in der Hauptfunktion genutzt werden muss [[atomar]] erfolgen. Das Vergessen dieser Regel führt selten zu Problemen, aber wenn dann zu schwer Nachvollziehbaren...

=== 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 Millisekunden (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% 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ößeren 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.
<syntaxhighlight lang="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;
}
</syntaxhighlight>

* 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/Images/Atmel-2521-AVR-Hardware-Design-Considerations_ApplicationNote_AVR042.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren]

AVR Checkliste

2015-06-09T08:35:30Z

80.64.189.58: IC's -> ICs

[[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 dringendsten 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 (internal R/C), mit einem externen Oszillator (external clock), mit einem Quarz (external crystal) oder mit einem Resonator (external R/C) betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu passt (z. B. external clock statt external crystal), 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 einmal möglich ===

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

In diesem Fall ist meistens der Resetpin kurzgeschlossen, daher lässt sich der AVR einmal 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 dienen dazu, impulsartige Einbrüche der Betriebsspannung, die durch schnelle Schaltvorgänge verursacht werden können, zu minimieren. Sie verhindern unkontrollierte Brownouts, welche durch diese Spannungseinbrüche auftreten können. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden:

* Ein Abblockkondensator sollte möglichst dicht am IC sitzen.
* Eine niederimpedante Anbindung sollte gegeben sein - also keine Stegleitungen. Dies bedeutet, das die Versorgungsspannung erst durch das Pad des Abblockkondensators fließen MUSS und dann weiter zum IC gereicht wird

* Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen.

* Bei ICs mit mehreren Anschlüssen für VCC sollte jeder VCC-Pin mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren). Dabei ist darauf zu achten, jeder Abblockkondensator mit einem eigenen Via auf die niederimpedante (heißt Hochfrequenz gut leiten) großflächige, nicht unterbrochene Massefläche kontaktiert wird.

* Es sollten keramische Kondensatoren mit einer Kapazität von maximal 100 nF verwendet werden. Größere Kondensatoren, etwa 10 µF-Elkos, sind für diese Aufgabe ''nicht'' geeignet, weil sie "zu langsam" sind (der Widerstand=Impedanz ist bei hochfrequenten Spannungen zu groß - ein schneller (hochfrequenter) Spannungsimpuls kann so nicht abgeleitet werden)!

=== 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 ICs mit mehreren Ground-Anschlüssen müssen immer 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, AT90PWM2/3/2B/3B 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 ==

=== Mainschleife vorhanden? ===

Insbesondere beim Testen von Interrupts kann es passieren, dass man keine eigentliche Programmschleife vorsieht, weil ja alles in den Interrupts passiert. Das führt dazu, dass der Controller nach Abarbeiten aller Befehle in <syntaxhighlight lang="c">int main(void) {}</syntaxhighlight> seine Arbeit einstellt und daher auch keine Interrupts mehr funktionieren. Demnach sollte bei rein Interrupt-basierten Programmen die Funktion mindestens so aussehen:
<syntaxhighlight lang="c">int main(void)
{
// hier Interrupts definieren
// und einschalten
while (1){}
}</syntaxhighlight>

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

Außerdem 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.
<syntaxhighlight lang="c">#include <avr/interrupt.h>

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

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:

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

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:

<syntaxhighlight lang="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
</syntaxhighlight>

=== 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.:
<syntaxhighlight lang="c">
TIFR = (1<<TOV0);
</syntaxhighlight>

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.

=== Wo nötig Variablenzugriff atomar gestaltet? ===
Der Zugriff auf Variablen >8 Bit welche in der ISR und in der Hauptfunktion genutzt werden muss [[atomar]] erfolgen. Das Vergessen dieser Regel führt selten zu Problemen, aber wenn dann zu schwer Nachvollziehbaren...

=== 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 Millisekunden (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% 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ößeren 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.
<syntaxhighlight lang="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;
}
</syntaxhighlight>

* 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/Images/Atmel-2521-AVR-Hardware-Design-Considerations_ApplicationNote_AVR042.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren]

AVR Checkliste

2015-06-09T08:35:08Z

80.64.189.58: Beschreibung Einsatzzweck Abblockkondensatoren korrigiert

[[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 dringendsten 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 (internal R/C), mit einem externen Oszillator (external clock), mit einem Quarz (external crystal) oder mit einem Resonator (external R/C) betrieben werden. Wenn die Einstellung über die Fusebits nicht dazu passt (z. B. external clock statt external crystal), 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 einmal möglich ===

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

In diesem Fall ist meistens der Resetpin kurzgeschlossen, daher lässt sich der AVR einmal 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 dienen dazu, impulsartige Einbrüche der Betriebsspannung, die durch schnelle Schaltvorgänge verursacht werden können, zu minimieren. Sie verhindern unkontrollierte Brownouts, welche durch diese Spannungseinbrüche auftreten können. Diesen Zweck erfüllen sie optimal, wenn folgende Regeln eingehalten werden:

* Ein Abblockkondensator sollte möglichst dicht am IC sitzen.
* Eine niederimpedante Anbindung sollte gegeben sein - also keine Stegleitungen. Dies bedeutet, das die Versorgungsspannung erst durch das Pad des Abblockkondensators fließen MUSS und dann weiter zum IC gereicht wird

* Jedes IC in einer Schaltung sollte einen Abblockkondensator besitzen.

* Bei ICs mit mehreren Anschlüssen für VCC sollte jeder VCC-Pin mit einem eigenen Abblockkondensator beschaltet werden (z. B. AVRs in SMD-Bauform wie dem ATmega16A also mit vier Kondensatoren). Dabei ist darauf zu achten, jeder Abblockkondensator mit einem eigenen Via auf die niederimpedante (heißt Hochfrequenz gut leiten) großflächige, nicht unterbrochene Massefläche kontaktiert wird.

* Es sollten keramische Kondensatoren mit einer Kapazität von maximal 100 nF verwendet werden. Größere Kondensatoren, etwa 10 µF-Elkos, sind für diese Aufgabe ''nicht'' geeignet, weil sie "zu langsam" sind (der Widerstand=Impedanz ist bei hochfrequenten Spannungen zu groß - ein schneller (hochfrequenter) Spannungsimpuls kann so nicht abgeleitet werden)!

=== 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 IC's mit mehreren Ground-Anschlüssen müssen immer 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, AT90PWM2/3/2B/3B 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 ==

=== Mainschleife vorhanden? ===

Insbesondere beim Testen von Interrupts kann es passieren, dass man keine eigentliche Programmschleife vorsieht, weil ja alles in den Interrupts passiert. Das führt dazu, dass der Controller nach Abarbeiten aller Befehle in <syntaxhighlight lang="c">int main(void) {}</syntaxhighlight> seine Arbeit einstellt und daher auch keine Interrupts mehr funktionieren. Demnach sollte bei rein Interrupt-basierten Programmen die Funktion mindestens so aussehen:
<syntaxhighlight lang="c">int main(void)
{
// hier Interrupts definieren
// und einschalten
while (1){}
}</syntaxhighlight>

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

Außerdem 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.
<syntaxhighlight lang="c">#include <avr/interrupt.h>

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

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:

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

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:

<syntaxhighlight lang="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
</syntaxhighlight>

=== 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.:
<syntaxhighlight lang="c">
TIFR = (1<<TOV0);
</syntaxhighlight>

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.

=== Wo nötig Variablenzugriff atomar gestaltet? ===
Der Zugriff auf Variablen >8 Bit welche in der ISR und in der Hauptfunktion genutzt werden muss [[atomar]] erfolgen. Das Vergessen dieser Regel führt selten zu Problemen, aber wenn dann zu schwer Nachvollziehbaren...

=== 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 Millisekunden (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% 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ößeren 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.
<syntaxhighlight lang="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;
}
</syntaxhighlight>

* 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/Images/Atmel-2521-AVR-Hardware-Design-Considerations_ApplicationNote_AVR042.pdf Application Note AVR042: AVR Hardware Design Considerations]
* [http://www.atmel.com/dyn/resources/prod_documents/doc1619.pdf Application Note AVR040: EMC Design Considerations]
* [http://www.youtube.com/watch?v=AP_FSyWGpoE Youtube-Video zum Thema Abblockkondensatoren]

Low Cost FPGA Konfiguration

2015-03-30T09:26:19Z

80.64.189.58: Orthographie

== Einleitung ==

Wenn man FPGAs auf selbst entworfenen Platinen einsetzen möchte, stellt sich oft das Problem des Konfigurationsspeichers. Die meisten FPGAs sind SRAM-basiert und haben keinen [[Speicher#NV-RAM | nichtflüchtigen]] Speicher auf dem Chip bzw. im gleichen Gehäuse (Ausnahmen sind Spartan-3N von Xilinx, XP und XP2 von Lattice und die FPGAs von Actel in Antifuse-Technologie). Also muss irgendwie ein Speicher her. Dazu gibt es mehrere Möglichkeiten.

{| border="1"
! Konfigurationsmethode || Vorteile || Nachteile
|-
| PC mit Programmierkabel || einfache und schnelle Programmierung || Platine kann nur mit PC genutzt werden
|-
| Spezial-PROM z. B. Xilinx XCFxxS || einfachste Anwendung || hoher Preis schlechte Verfügbarkeit für Hobbybastler
|-
| Standard-EEPROM mit [[SPI]] || einfache Anwendung billig || nur bei einigen FPGA-Familien möglich (z. B. Spartan3E)
|-
| Mikrocontroller mit internem oder externem Flash || sehr gute Verfügbarkeit für Hobbybastler billig || zusätzlicher Mikrocontroller nötig wenn das FPGA allein auf der Platine betrieben wird Zusatzaufwand für die Programmierung des EEPROMs und Mikrocontrollers
|}

Dieser Artikel soll die letzte Methode näher beleuchten. Dabei wird ein FPGA vom Typ Spartan 2 von [http://www.xilinx.com Xilinx] sowie ein [[Mikrocontroller]] der [[AVR]]-Familie vom Typ Tiny12 von Atmel eingesetzt. Da die FPGAs anderer Hersteller aber sehr ähnlich konfiguriert werden, kann man das Ganze leicht anpassen.

== FPGA Konfiguration mit Mikrocontroller ==

Für kleine bis mittlere FPGAs wird nur verhältnismässig wenig Konfigurationsspeicher benötigt. Auf der anderen Seite gibt es kleine [[Speicher#EEPROM | EEPROMs]] im SO-8 Gehäuse mit [[I2C]] Schnittstelle. Damit kann sehr kostengünstig und platzsparend die Konfiguration gespeichert werden. Nun braucht man nur noch einen kleinen Mikrocontroller, welcher das EEPROM ausliest und die Daten zum FPGA schickt. Glücklicherweise gibt es auch die im sehr kleinen SO-8 Gehäuse. Damit ist die Lösung sehr platzsparend.

{| border ="1"
! rowspan="2"| FPGA-Familie
! rowspan="2"| Typ
! rowspan="2"| Konfiguration [Bit]
! colspan="3" | EEPROM-Anzahl
! rowspan="2" | Konfigurationszeit [s] I2C mit 400kBit/s
|-
! 24C128 || 24C256 || 24C512
|-
|rowspan="6" | Spartan 2
| XC2S15
| align="right" | 197.696
| align="center" | 2
| align="center" | 1
| align="center" | 1
| align="center" | 0,5
|-
| XC2S30
| align="right" | 336.768
| align="center" | 3
| align="center" | 2
| align="center" | 1
| align="center" | 0,8
|-
| XC2S50
| align="right" | 559.200
| align="center" | 5
| align="center" | 3
| align="center" | 2
| align="center" | 1,4
|-
| XC2S100
| align="right" | 781.216
| align="center" | 6
| align="center" | 3
| align="center" | 2
| align="center" | 2
|-
| XC2S150
| align="right" | 1.040.096
| align="center" | 8
| align="center" | 4
| align="center" | 2
| align="center" | 2,6
|-
| XC2S200
| align="right" | 1.335.840
| align="center" | *
| align="center" | 6
| align="center" | 3
| align="center" | 3,3
|-
| rowspan="4" | Spartan 3
| XC3S50
| align="right" | 439.264
| align="center" | 4
| align="center" | 2
| align="center" | 1
| align="center" | 1,1
|-
| XC3S200
| align="right" | 1.047.616
| align="center" | 8
| align="center" | 4
| align="center" | 2
| align="center" | 2,6
|-
| XC3S400
| align="right" | 1.699.136
| align="center" | *
| align="center" | 7
| align="center" | 4
| align="center" | 4,2
|-
| XC3S1000
| align="right"| 3.223.488
| align="center" | *
| align="center" | *
| align="center" | 7
| align="center" | 8,1
|}

== Schaltung ==

Die Schaltung ist recht einfach. Über den [[I2C]]-[[Bus]] wird ein oder mehrere EEPROMs ausgelesen. Zur Konfiguration sind nur die vier Signale CCLK, Din, Done und PROGRAM benötigt. Der FPGA wird im ''Slave Serial Mode'' betrieben. Da der 8-polige Mikrocontroller aber nur 5 wirklich freie IO-Pins hat, müssen Reset und PROGRAM verbunden werden. Das ist aber kein Problem, im Gegenteil, hier werden FPGA und Mikrocontroller parallel in den Resetzustand versetzt, wenn die Versorgungsspannung angelegt wird oder manuell PROGAMM auf LOW gezogen wird. Es ist jeder beliebige [[AVR]] verwendbar, da das Programm sehr klein ist und keinerlei spezielle Resourcen benötigt, nicht einmal SRAM. Es können EEPROMs mit 128, 256 oder 512kbit eingesetzt werden. Allerdings müssen alle die gleiche Grösse haben. Eine LED am Signal SDA wird zur Fehleranzeige verwendet. Es sollte ein Low Current Typ mit niedriger Flusspannung sein (also keinen blauen oder weissen [[LED]]s). R5 dient der Entkopplung von DONE zur [[ISP]]-Schnittstelle. Damit kann der AVR in der Schaltung programmiert werden.

[[bild: fpga_config.png | thumb | left | 640px| Schaltplan des FPGA Konfigurators]]
 

== Programmierung des Mikrocontrollers ==

Die Programmierung des Konfigurationsprogramms erfolgt in Assembler. Zum einen um eine minimale Programmgröße und maximale Geschwindigkeit zu erzielen. Zum anderen, weil kleine AVRs ohne SRAM vom AVR-GCC nicht unterstützt werden. Das ist aber unkritisch, das Programm ist klein und damit überschaubar.

Nach dem Reset wird der Oszillator auf maximalen Takt gestellt, der ist beim Tiny12 sowieso nicht so hoch, max. 2,5 MHz. Dann werden die IOs und Variablen initialisiert. Am I2C-Bus können maximal acht EEPROMs angeschlossen werden, weil diese ICs nur maximal drei konfigurierbare Adressbits besitzen, einige Typen sogar nur zwei. Wenn die Größe der Konfigurationsdatei die Größe eines einzelnen EEPROMS übersteigt, muss schrittweise aus den einzelnen EEPROMs gelesen werden. Dazu muss der jeweilige EEPROM zum Beginn adressiert werden. Danach können lückenlos die Daten aus dem EEPROM gelesen werden. Nachdem alle Bytes geladen wurden wird noch ein zusätzliches Byte geschickt, um die Startsequenz des FPGAs auszulösen. Ist die Konfiguration erfolgreich verlaufen ist danach der FPGA in Funktion. Das wird durch das Signal ''Done'' angezeigt.

<syntaxhighlight lang="avrasm">
.include "tn12def.inc"

;*******************************************************************************
;*
;* A small but fine FPGA configurator
;* using a Tiny 12 and serial EEPROMs
;*
;* Up to eigth EEPROMs can be cascaded on the I2C bus
;* All devices must be of same size
;*
;* theoritical limit is 8x64kB = 512 kB
;*
;* Examles for FPGA config size
;* Spartan-II : XC2S200(biggest family member): 166,980 Bytes
;* Spartan-3 : XC3S1000 : 402,936 Bytes
;*
;* Configuration speed is ~8.5kBytes/s @ 2MHz
;* Top speed is ~ 43kB/s @ 10 MHz, 400kHz limit of I2C
;*
;* example uses a Xilinx XC2S30 with 42.096 bytes config size
;* and a ST24C512 with 64 kB

.equ fpga_size = 42096; ; FPGA config file size
.equ EEPROM_size = 65536; ; EEPROM size per device
.equ F_CPU_MHz = 2; ; CPU clock in MHz, 1..10

.equ bitreverse = 0

;* = 0 , bits will be copied bit by bit from EEPROM to FPGA, faster configuration
;* binary files must have same bitorder as required by FPGA (MSB first)
;* For Xilinx, the bit files must be processed by bitdreher.exe!!!

;* = 1 , bits will be copied byte by bytes from EEPROM and written bit reversed to FPGA, slow configuration
;* binary files must have reverse bitorder as required by FPGA (LSB first)
;* For Xilinx, the bit files are generated this way by default

;*******************************************************************************

.equ cfg_port = portb
.equ cfg_ddr = ddrb
.equ cfg_pin = pinb

.equ DIN = PB0 ; FPGA serial configuration
.equ DONE = PB1
.equ CCLK = PB2
.equ SDA = PB3 ; Connection to I2C EEPROM
.equ SCL = PB4

; Reset is connected to FPGA AND AVR, so we have a automatic Power-on reset

; some marcos to support readability

.macro SDA_LOW
sbi cfg_ddr, sda ; open drain, low
.endmacro

.macro SDA_HIGH
cbi cfg_ddr, sda ; open drain, high
.endmacro

.macro SCL_LOW
sbi cfg_ddr, scl ; open drain, low
.endmacro

.macro SCL_HIGH
cbi cfg_ddr, scl ; open drain, high
.endmacro

.macro DIN_LOW
cbi cfg_port, din ; push pull
.endmacro

.macro DIN_HIGH
sbi cfg_port, din ; push pull
.endmacro

.macro CCLK_LOW
cbi cfg_port, cclk ; push pull
.endmacro

.macro CCLK_HIGH
sbi cfg_port, cclk ; push pull
.endmacro

.macro i2c_error_check
brts PC+2
rjmp error_i2c
.endmacro

; add a delay to reach given delay time
; usage
; delay_1 time [Unit 0.1us], clocks_already_done
.macro delay

; calculate number of remaining clocks
; +1 is safety margin to account for integer truncation

.set clks = @0*F_CPU_MHz/10-@1+1

; use optimized delay blocks with "nonsense" commands to have maximum
; delay with minimum code size

.if clks==1
nop
.endif

.if clks==2
ld null, z
.endif

.if clks==3
lpm
.endif

.if clks==4
lpm
nop
.endif

.if clks==5
lpm
ld null, z
.endif

.if clks==6
lpm
lpm
.endif

.if clks==7
lpm
lpm
nop
.endif

.if clks==8
lpm
lpm
ld null,z
.endif

.if clks==9
lpm
lpm
lpm
.endif

.if clks==10
lpm
lpm
lpm
nop
.endif

.if clks==11
lpm
lpm
lpm
ld null, z
.endif

.if clks==12
lpm
lpm
lpm
lpm
.endif

.if clks==13
lpm
lpm
lpm
lpm
nop
.endif

.if clks==14
lpm
lpm
lpm
lpm
ld null, z
.endif

.endmacro

.def zero = r1 ; always zero
.def one = r2 ; always one
.def null = r3 ; write only ;-)
.def tmp1 = r16 ; general purpose
.def tmp2 = r17
.def tmp3 = r18
.def cnt0 = r19 ; loop counter, 24 Bit
.def cnt1 = r20
.def cnt2 = r21
.def i2c = r22 ; I2C address, used for multiple devices
.def abs0 = r23 ; data counter, 24 Bit
.def abs1 = r24 ;
.def abs2 = r25

;*
;*******************************************************************************

.cseg
; lets go

; initialize stack

; hardware stack for Tiny12, no init necessary

; full speed, ~2 MHz with ATtiny12

ldi tmp1,0xFF
out osccal, tmp1

; config IOs

ldi tmp1, (1<<cclk) | (1<<din)
out cfg_ddr,tmp1

ldi tmp1, (1<<done)
out cfg_port,tmp1 ; internal pull up for DONE

; generate constant registers

sub zero,zero
ldi tmp1,1
mov one,tmp1
ldi i2c,0xA0 ; I2C base address

; set byte counter

ldi abs0,byte1(fpga_size)
ldi abs1,byte2(fpga_size)
ldi abs2,byte3(fpga_size)

; wait 10ms for FPGA to finish power up and clear config space

ldi tmp1,10
rcall wait

; when using multiple EEPROMs, we must address them individual

device_loop:

; number of remaining bytes >EEPROM_size ?

ldi tmp1,byte1(EEPROM_size)
ldi tmp2,byte2(EEPROM_size)
ldi tmp3,byte3(EEPROM_size)

cp abs0,tmp1
cpc abs1,tmp2
cpc abs2,tmp3
brge device_loop_big ; >= EEPROM_size

; less than EEPROM_size, copy remaining bytes
mov cnt0,abs0 ; remaining bytes
mov cnt1,abs1
mov cnt2,abs2
mov abs0,zero ; set zero
mov abs1,zero
mov abs2,zero
rjmp device_loop_init

device_loop_big:
mov cnt0,tmp1 ; EEPROM_size loop
mov cnt1,tmp2
mov cnt2,tmp3
sub abs0,tmp1 ; - EEPROM_size
sbc abs1,tmp2
sbc abs2,tmp3

device_loop_init:
subi cnt0,1 ; -1, since last byte must be read with no ACK
sbci cnt1,0 ; outside the loop
sbci cnt2,0

; write first adress

rcall i2c_start
mov tmp1, i2c ; load i2c address
rcall i2c_write
i2c_error_check
ldi tmp1, 0 ; write adress 0
rcall i2c_write
i2c_error_check
ldi tmp1, 0
rcall i2c_write
i2c_error_check
rcall i2c_stop

rcall i2c_start
mov tmp1, i2c ; load i2c address
subi tmp1,-1 ; +1, read access
rcall i2c_write
i2c_error_check
set ; set T-Flag, continous reading

main_loop:

.if bitreverse==1
; configuration uses online bit reverse, slow

rcall i2c_read
rcall fpga_write

.else
; configuration uses offline bit reverse, fast (bitdreher.exe)

; read a byte from I2C and parallel send it to the FPGA
; fast version
ldi tmp2, 8 ; loop counter

main_bit_loop:
scl_high ; SCL rising edge
sbic cfg_pin,sda ; copy SDA to Din
din_high
sbis cfg_pin,sda
din_low
delay 7, 6 ; minimum LOW time 0,6µs + 0.1µs safty margin
scl_low ; falling edge generates new bit
cclk_high ; LOW time min. 9 CLKs
cclk_low
delay 14, 9 ; minimum HIGH time 1,3µs + 0.1µs safty margin
dec tmp2
brne main_bit_loop

; write ACK to EEPROM

sda_low ; write ACK, more to read
delay 1, 0
scl_high
delay 7, 2
scl_low
sda_high
delay 14, 10

.endif

subi cnt0,1 ; decrement data counter
sbci cnt1,0
sbci cnt2,0
brne main_loop

clt ; no ACK for last byte of block
rcall i2c_read
rcall fpga_write

rcall i2c_stop
subi i2c,-2 ; +2, increment I2C address bits

; number of remaining data bytes = 0 ?

cp abs0,zero
cpc abs1,zero
cpc abs2,zero
breq main_end ; nothing left to copy, finish

rjmp device_loop ; process next data block

main_end:
ldi tmp1,0
rcall fpga_write ; one more dummy byte for FPGA startup

ldi tmp1,1
rcall wait ; wait for DONE to go HIGH (open drain)
sbis cfg_pin, done ; check if DONE is HIGH (= FPGA config OK)
rjmp error_fpga ; something went wrong during configuration
ldi tmp1, (1<<SE) | (1<<SM)
out mcucr,tmp1 ; power down sleep mode
sleep ; good night

; no wake up here, only through reset

; i2c has no ACK, fast blinking

error_i2c:
sda_low
ldi tmp1,100
rcall wait
sda_high
ldi tmp1,100
rcall wait
rjmp error_i2c

; FPGA configuration error, DONE stays low, slow blinking

error_fpga:
sda_low
ldi tmp1,250
rcall wait
ldi tmp1,250
rcall wait
sda_high
ldi tmp1,250
rcall wait
ldi tmp1,250
rcall wait
rjmp error_fpga

; *****************************************************************************

; functions

; *****************************************************************************

; just wait N*1ms, N is given in tmp1

wait:
ldi tmp2,20*F_CPU_MHz
wait_1:
ldi tmp3,16
wait_2:
dec tmp3
brne wait_2
dec tmp2
brne wait_1
dec tmp1
brne wait
ret

; *****************************************************************************

; write a byte to I2C
; input : tmp1 : data
; output : T-flag : ACK (0= NACK (SDA high), 1 = ACK (SDA low))

i2c_write:
ldi tmp2, 8 ; loop conter
i2c_write_loop:

sbrs tmp1,7 ; copy MSB to SDA
sda_low
sbrc tmp1,7
sda_high

delay 14, 8
scl_high
delay 7, 2
scl_low
lsl tmp1 ; get next bit
dec tmp2
brne i2c_write_loop

; check ACK from EEPROM
sda_high
delay 14, 5
scl_high
clt ; clear T-Flag, = no ACK!
sbis cfg_pin,sda ; check SDA is ACK=0 (positive ACK)
set ; ACK=0, OK
delay 7, 5
scl_low
delay 14, 7
ret

; *****************************************************************************

; read a byte from I2C
; input : T-flag : ACK, (0= NACK (SDA high), 1 = ACK (SDA low))
; output : tmp1 : data
i2c_read:
ldi tmp2, 8 ; loop conter
i2c_read_loop:
scl_high
clc ; copy SDA to carry
sbic cfg_pin, sda ; read SDA
sec ; set carry
rol tmp1 ; shift in next bit
delay 7, 6
scl_low ; minimum pulse width LOW = 1.3µs = 13 clks @10 MHz
delay 14, 5
dec tmp2
brne i2c_read_loop

; write ACK to EEPROM

brtc i2c_read_no_ack
sda_low ; write ACK, more to read
rjmp i2c_read_send_ack
i2c_read_no_ack:
sda_high ; no ACK, stop reading
i2c_read_send_ack:
delay 14, 6
scl_high
delay 7, 2
scl_low
sda_high ; release SDA
ret

; *****************************************************************************

; Create a I2C START Condition

i2c_start:
delay 5, 2
sda_low
delay 5, 2
scl_low
delay 30, 7
ret

; *****************************************************************************

; Create a I2C STOP Condition

i2c_stop:
delay 5, 2
sda_low
delay 5,2
scl_high
delay 5,2
sda_high
delay 30, 7
ret

; *****************************************************************************

; write a byte to FPGA, with bit reversal
; input : tmp1 : data

.if bitreverse==1
.message "Bit reverse ON, slow configuration."
; configuration uses online bit reverse, slow
; bit reverse, LSB first
fpga_write:
ldi tmp2, 8 ; loop conter
fpga_write_loop:

sbrs tmp1,0 ; copy LSB to DIN
din_low
sbrc tmp1,0
din_high

cclk_high ; generate cclk pulse
cclk_low
lsr tmp1 ; get next bit
dec tmp2
brne fpga_write_loop
ret

; *****************************************************************************
.else
.message "Bit reverse OFF, fast configuration."
; configuration uses offline bit reverse, fast (bitdreher.exe)
; no bit reverse, MSB first
fpga_write:
ldi tmp2, 8 ; loop conter
fpga_write_loop:

sbrs tmp1,7 ; copy MSB to DIN
din_low
sbrc tmp1,7
din_high

cclk_high ; generate cclk pulse
cclk_low
lsl tmp1 ; get next bit
dec tmp2
brne fpga_write_loop
ret

; *****************************************************************************
.endif
</syntaxhighlight>

== Fehlererkennung ==

Seitens des FPGAs ist Done ein [[Ausgangsstufen Logik-ICs#Open Collector | Open Drain]] Ausgang. Im AVR wird der interne Pull-Up eingeschaltet, um das Signal auf HIGH ziehen zu können. Ist jedoch ein Fehler aufgetreten (CRC-Fehler im Datenstrom), bleibt Done auf LOW. Der AVR prüft Done am Ende der Konfiguration. Ist Done gleich HIGH, geht er in den Power Down [[Sleep Mode]] um Strom zu sparen. Ist aber ein Fehler aufgetreten und Done somit LOW, wird das durch langsames Blinken der LED an SDA angezeigt (~1 Hz). Tritt während der Adressierung des EEPROMs ein Fehler auf (kein ACK vom EEPROM), dann wird dies durch schnelles Blinken der LED angezeigt (~5 Hz). Im Normalfall treten diese Ereignisse nur sehr selten auf, z. B. bei einem EEPROM-Defekt durch Alterung/Datenverlust oder einer Störung der Datenübertragung durch starke Störimpulse. Aber zur Programmierung und zum Testen sind sie sehr nützlich.

== Nutzung ==

Die Nutzung der Schaltung ist recht einfach. Im Quellcode müssen nur drei Variablen an das jeweilige Projekt angepasst werden. Soll ein anderer AVR-Typ verwendet werden können auch die Pins einfach zugewiesen werden. Danach wird das Programm assembliert und per [[ISP]] in den AVR geschrieben. Abschliessend sollten die Fuses gesetzt werden. Der Takt des interen RC-Oszillators sollte möglichst hoch gewählt werden, bis ca. 10 MHz ist das Progamm ohne Änderungen nutzbar. Wenn verfügbar sollte der Brown Out Detector eingeschaltet werden und mit ca. 2,7V Schwellspannung betrieben werden. Für den hier verwendeten Tiny12 muss das Fuse-Byte mit 0x12 beschrieben werden. '''HALT!''' Wenn jetzt der Reset gelöst wird läuft der AVR sofort los und versucht die Daten aus den EEPROMs zu lesen. Da diese aber noch nicht programmiert sind werden keine sinnvollen Daten ins FPGA geladen. Das schadet dem FPGA zwar nicht, aber die Konfiguration scheitert! In der Folge wird SDA vom AVR kontinuierlich zwischen LOW und HIGH umgeschaltet, um den Fehler durch Blinken der LED zu signalisieren. Damit ist aber keine Programmierung der EEPROMs mehr möglich!

Mögliche Auswege:

* RESET auf LOW halten
* die EEPROMs '''vor''' dem AVR programmieren

Im Normalfall wird man den zweiten Weg wählen. Denn während der Entwicklung wird man meist das FPGA über [[JTAG]] konfigurieren. Erst wenn alles komplett funktioniert wird man die Konfiguration einmalig in den EEPROM schreiben.

'''Hinweis!''' Wird während der Entwicklungsphase das FPGA über JTAG programmiert, muss in den Optionen für "Generate Programming File" unter Startup Options -> FPGA Start-up Clock "JTAG" gewählt werden.

Die Programmierung der EEPROMs erfolgt mit [http://www.lancos.com Ponyprog]. Mittels einfachem Adapter kann man direkt auf den I2C-Bus gehen, es werden nur SDA, SCL und GND benötigt, die Pull-Ups sind schon auf dem Board. Das Board muss dazu natürlich mit Spannung versorgt werden.

[[bild:i2c_adapter.png| framed | left | I2C Adapter für Ponyprog]]
 

Der Ablauf der EEPROM-Programmierung sieht wie folgt aus:

* In den Optionen für "Generate Programming File" muss unter Startup Options -> FPGA Start-up Clock "CCLK" gewählt werden.
* Im Xilinx ISE den kompletten Synthesezyklus inclusive "Generate Programming File" durchlaufen.
* IMPACT starten und eine PROM-Datei im BIN Format erzeugen.
* Jetzt hat man die Wahl zwischen zwei Möglichkeiten.
** Die Daten direkt in den EEPROM schreiben. Dann müssen sie beim Lesen und anschliessender Ausgabe zum FPGA in der Reihenfolge der Bits vertauscht werden, das kostet natürlich Zeit
** Die Daten mit einem kleinen Tool [[media:Bitdreher.zip | Bitdreher]] umwandeln. Dabei wird die Bitverdrehung vorher durchgeführt. Die Daten können damit ohne zusätzliche Verdrehung schnell ins FPGA geschrieben werden.
* Ponyprog starten, EEPROM Familie "IC Bus 16bit eeprom" auswählen, den jeweiligen Typ auch auswählen (25C128, 24C256, 24C512).
* Die Bin-Datei laden und "Write Device" ausführen.
* Das erfolgreiche Programmieren und Verifizieren wird von Ponyprog angezeigt.

Wenn die FPGA-Konfiguration grösser als ein EEPROM ist, muss die Datei in mehrere Stücke aufgeteilt werden. Das kann man mit IMPACT machen oder '''promgen''' direkt von der Kommandozeile aufrufen. Die Option ''-s <size>'' erlaubt das Aufteilen der Konfigurationsdaten in kleinere Dateien. Beachtet werden muss dabei, dass die einzelnen Blöcke exakt so gross sein müssen wie ein einzelner EEPROM. Ausser natürlich der letzte Block, dessen Länge ergibt sich aus (Dateigrösse MODULO EEPROM-Grösse). Die einzelnen Dateien können dann einfach per Ponyprog in die EEPROMs geschrieben werden.

'''Achtung!'''
*Dabei muss man aufpassen, dass die Reihenfolge nicht verwechselt wird! Der erste Block muss in den EEPROM mit Adresse 0, der zweite in den mit Adresse 1 usw.
* Wenn man mit Ponyprog mehrere EEPROMs an einem Bus programmieren will, muss die Adresse der EEPROMs manuell in der Datei ''PONYPROG2000.INI'' in der Zeile
<pre>
I2CBaseAddress=0xA0
</pre>
: eingetragen werden (0xA0, 0xA2, 0xA4, 0xA6, 0xA8, 0xAA, 0xAC, 0xAE). Nach jeder Änderung muss Ponyprog neu gestartet werden.

== Leistung ==

Auf einem Tiny12 mit voll aufgedrehtem RC-Oszillator (ca. 2 MHz) und einer Online Bitverdrehung (bitreversal=1) erreicht man eine Geschwindigkeit von ca. 8,5kB/s, d.h. der im Test verwendete FPGA vom Typ XC2S30 mit 42096 Bytes Konfigurationsspeicher wird in ca. 5s konfiguriert. Nicht gerade berauschend, aber ausreichend. Der Grund dafür liegt nicht nur in der begrenzten Geschwindigkeit des I2C Busses (400kHz), sondern in einer Merkwürdigkeit der Konfigurationssoftware von Xilinx. Diese verdreht nämlich die Bits innerhalb der Bytes aus fadenscheinigen Gründen (Bit 0<->7, Bit 1<->6, etc.). Damit muss aber immer zunächst ein Byte vollständig gelesen werden (MSB zuerst) und dananch in umgekehrter Reihenfolge ausgegeben werden (LSB zuerst). Das kostet einiges an Zeit. Damit werden bei 2 MHz nur etwa 15% der maximalen Geschwindigkeit erreicht, dementsprechend sind die Konfigurationszeiten etwa sechs mal so lang wie in der Tabelle oben angegeben. Mit dem Parameter bitreversal=0 und der Bearbeitung der Konfigurationsdaten mit dem Tool [[media:Bitdreher.zip | Bitdreher]] erreicht man eine Konfigurationszeit von ca 3s, 40% schneller! Die erreichbaren Konfigurationszeiten sind in nachfolgender Tabelle exemplarisch angegeben, mit dem in Klammern angegebenen Faktor kann man direkt in die zweite Tabelle gehen und die reale Konfigurationszeit ausrechnen. Bei höherem Prozessortakt werden längere Pausen eingefügt, sodass die minimalen Pulszeiten für 400kHz auf dem I2C-Bus eingehalten werden. Dies wird mit dem schönen, leistungsfähigen Makro ''delay'' erreicht.

{| border="1"
! rowspan="2" | Takt [MHz]
! colspan="2" | Konfigurationszeit [s] (Faktor)
|-
! bitreversal=0 || bitreversal=1
|-
| align="center" | 2
| align="center" | 3,0 (3,8)
| align="center" | 4,8 (6)
|-
| align="center" | 5
| align="center" | 1,2 (1,5)
| align="center" | 2,1 (2,6)
|-
| align="center" | 10
| align="center" | 0,9 (1,1)
| align="center" | 1,4 (1,8)
|}

== Zukunftsaussichten ==

Für grössere FPGAs werden die seriellen EEPROMs irgendwann zu klein und zu langsam. Hier müssen andere Datenträger her. SD-Karten sind klein, billig und weit verbreitet. Auch wenn der Aufwand zu deren Ansteuerung plus Minimalfunktionalität für FAT12/FAT16 um einiges höher liegt, ist dies ein interessanter Ansatzpunkt, der in Zukunft einmal umgesetzt werden kann.

Als Zwischenlösung bieten sich Flashbausteine mit [[SPI]] im SO-8 Gehäuse an, die gibt es bis zu unglaublichen 32 Mbit zum Spottpreis, z.b. bei [[Elektronikversender#csd-electronics | CSD]]. Allerdings muss dann ein AVR mit zwei zusätzlichen Pins her, hier muss man dann auf ein 20 poliges Gehäuse wechseln. Enthusiasten nehmen das platzsparende MLF20 ;-).

Alternativ könnte geprüft werden, ob der Dataflash eines [[AVR_Butterfly]] ausreicht. Siehe: [[FPGA_Konfiguration_mit_AVR_Butterfly]]

== Diskussion im Forum ==
* [http://www.mikrocontroller.net/topic/79844 Programm auf Spartan 3A laden]
* [http://www.mikrocontroller.net/topic/83026 FPGA synthetisierung]
* [http://www.mikrocontroller.net/topic/80275 Einsteigerfreundlicher FPGA]
* [http://www.mikrocontroller.net/topic/78362 Spartan 3E mit SPI-Flash]
* [http://www.mikrocontroller.net/topic/75954 Spartan 3e: Anfägerhilfe bei Flashspeicherung]
* [http://www.mikrocontroller.net/topic/39941 Programmier-Hardware Altera Cyclone-II /EPCS4]
* [http://www.mikrocontroller.net/topic/39947 FPGA und CPLD programmieren]

== Links ==

* [http://www.xilinx.com FPGAs von Xilinx]
* [http://www.lancos.com PonyProg]
* [http://www.atmel.com/products/serial/default.asp Serielle EEPROMs bei Atmel]
* [http://www.atmel.com/dyn/resources/prod_documents/doc3301.pdf Configuring High-density FPGAs using Atmel’s Serial DataFlash® and an AVR® Microcontroller (2003)]
* [http://www.xilinx.com/publications/xcellonline/xcell_55/xc_pdf/xc_spi55.pdf XC-SPI55 Program SPI Serial Flash from Xilinx FPGAs and CPLDs (2005)]
* [http://www.xilinx.com/support/documentation/application_notes/xapp445.pdf XAPP445 Configuring Spartan-3E FPGAs with SPI Flash Memories (2007)]
* [http://www.xilinx.com/support/documentation/application_notes/xapp693.pdf XAPP693 CPLD-Based Configuration...for Xilinx Platform Flash PROMs and FPGAs (2005)]
* [http://www.xilinx.com/support/documentation/application_notes/xapp176.pdf XAPP176 Configuration and Readback of the Spartan-II and Spartan-IIE Families (2002)]
* [http://www.xilinx.com/support/documentation/application_notes/xapp098.pdf XAPP098 The Low-Cost, Efficient Serial Configuration of Spartan FPGAs (1998)]

[[Category:FPGA-Projekte]]

ESP8266

2015-02-04T09:22:25Z

80.64.189.58: Orthografie

[[Datei:ESP8266.jpg|thumb|300px|ESP8266, Funkmodul]]
Das [[ESP8266]] von dem Hersteller Espressif ist ein programmierbarer WLAN-SoC mit [[UART]]- und [[SPI]]-Schnittstelle. '''WLAN'''-Funkmodule mit ESP8266 sind ab 3€ verfügbar. Die UART-Schnitttstelle ermöglicht eine einfache Integration in Mikrocontrollerprojekte.

== Spezifikation ==
Laut Hersteller <ref>[http://espressif.com/en/products/esp8266 ''Herstellerseite - unter Details''] Abgerufen am 26. August 2014.</ref>. :
* 802.11 b/g/n
* Wi-Fi Direct (P2P), soft-AP
* Integrated TCP/IP protocol stack
* Integrated TR switch, balun, LNA, power amplifier and matching network
* Integrated PLLs, regulators, DCXO and power management units
* +19.5dBm output power in 802.11b mode
* Power down leakage current of <10uA
* Integrated low power 32-bit CPU could be used as application processor
* SDIO 1.1/2.0, SPI, UART
* STBC, 1×1 MIMO, 2×1 MIMO
* A-MPDU & A-MSDU aggregation & 0.4ms guard interval
* Wake up and transmit packets in < 2ms
* Standby power consumption of < 1.0mW (DTIM3)
* VCC: 3,3V (Achtung: Eingänge sind '''NICHT 5V TOLERANT'''!)
Weiterhin:
* GPIOs, ADC

=== Datendurchsatz/Performanz ===
[https://www.mikrocontroller.net/topic/342240?page=single#3857630 Beitrag im Forum mit Tests: TCP: bis zu 7 MBit/s] 
[http://bbs.espressif.com/viewtopic.php?f=7&t=24 Beitrag Espressif-Form: UART loopback: 4.5 Mbps]
 
Bei den chinesischen Modulen mit Firmware 0.9.1 werden Ping Befehle unabhängig von der Paketgröße typischerweise in 30-150ms beantwortet. Datenpakete, die man vom PC aus an das Modul sendet werden unabhängig von der Paketgröße typischerweise nach 100-200ms quittiert.

== WLAN-Module mit ESP8266 ==
Es existieren ca. 11 Varianten von chinesischen Herstellern. Beispielsweise mit PCB- oder Keramik-Antenne oder mit u.fl.
 
Die Firmware 0.9.1 unterstützt bis zu vier gleichzeitige TCP oder UDP Verbindungen. Sie kann sich in vorhandene WLAN Netze einbuchen, aber auch selbst Access-Point mit DHCP Server sein. Der Access-Point ist zu Android kompatibel (mit 4.1.2 getestet).
 
Die Firmware enthält jedoch keinen Router. Mehrere Computer, die mit dem Modul als Access-Point verbunden sind, können keine Verbindung zueinander aufbauen.
Das Feature nennt sich AP Isolation.
 
#Produktbeschreibung: [[http://playground.boxtec.ch/doku.php/wireless/esp8266]]

=== Pinbelegung einiger ESP8266-Module ===
<gallery>
Datei:ESP8266-PinBelegung1.jpg|Pinbelegung - Groß mit PCB-Antenne
Datei:ESP8266-PinBelegung2.jpg|Pinbelegung - Klein mit Keramik-Antenne
</gallery>
Quelle <ref>[http://pan.baidu.com/share/link?shareid=727869034&uk=1900861665 ''Seller Information''] Abgerufen am 26. August 2014.</ref>.

== AT-Befehle für eine Firmware auf Basis des SDK-Beispiels "AT"==

Einstellen des Moduls als AP

Da wir nicht wissen, in welchem Modus sich das Modul gerade befindet, fragen wir diesen ab mit dem
Befehl AT+CWMODE? Das Modul antwortet mit

AT+CWMODE?<\r><\r><\n>+CWMODE:1<\r><\n>
<\r><\n>
OK<\r><\n>
In diesem Fall ist das Modul aktuell im Modus 1 ( Station) eingestellt. Also ändern wir den Modus auf 2 ( AP)
mit dem Befehl AT+CWMODE=2. Nach diesem Befehl ist ein Reset des Moduls erforderlich, damit die Änderung
sichtbar wird. Mit dem Befehl AT+RST führen wir diesen durch. Das Modul startet neu und die Stromaufnahme
steigt auf ca 80 mA. Das Modul ist jetzt als WLAN AP im Wireless Lan sichtbar.

Jetzt müssen wir noch einstellen, dass wir mehrere Verbindungen gleichzeitig haben wollen und den TCP Server starten und einstellen. Mit dem Befehl AT+CIPMUX=1 sagen wir dem Modul, dass wir mehrere Verbindungen haben wollen. Und mit dem Befehl AT+CIPSERVER=1,2526 starten wir den TCP Server und lassen ihn auf Port 2526 laufen. Sobald sich ein Client verbindet, sendet das Modul 'Link' + LF + CR. Beim Trennen einer Verbindung vom Client kommt 'Unlink' + LF + CR.

Ab hier können wir uns über einen TCP Socket auf Port 2526 mit dem Modul verbinden und Daten austauschen. Empfangene Daten werden folgendermaßen angezeigt. Gesendet wurde "Hallo Leute" + LF + CR.

<\r><\n>
+IPD,0,11:Hallo Leute<\r><\n>
OK<\r><\n>

+IPD kommt immer, 0 ist die erste Verbindung. Wenn 2 Geräte gleichzeitig eine Verbindung aufgebaut haben, steht dort eine 1. 11 Zeichen wurden empfangen, dann kommen die Daten.

Zum Senden von Daten vom Modul zum Client geht man folgenderweise vor. Erstmal sagen wir dem Modul, wieviele Daten wir an welche Verbindung schicken wollen. Mit dem Befehl AT+CIPSEND=0,5 z. B. sagen wir dem Modul wir möchten 5 Bytes an Verbindung 0 senden. Nach diesem Befehl werden die nächsten 5 Zeichen direkt an die Verbindung weitergereicht.
Sollte keine aktive Verbindung bestehen, sendet das Modul
AT+CIPSEND=0,5<\r><\r><\n>link is not<\r><\n>
ansonsten kommt
<\r><\n> >
und man kann Daten senden. Nach dem absenden der Daten 'Leute' + LF + CR sendet das Modul
Leute<\r><\r><\n>busy<\r><\n>
<\r><\n>
busy<\r><\n>
<\r><\n>
SEND OK<\r><\n>

Einstellen des Moduls als Station

== Software Development Kit (SDK) ==
Mit dem SDK können eigene Applikationen programmiert und die im SDK vorhandenen Beispiele "AT" und "IoT" verändert werden. Das SDK wird vom Hersteller zur Verfügung gestellt (Stand 25.10.2014). Passend zum SDK existiert eine virtuelle Maschine mit eingerichtetem gcc zum Kompilieren. Insbesondere der nun verfügbare gcc basiert auf einer Community-Entwicklung.

[http://bbs.espressif.com/viewforum.php?f=5&sid=3cf7540ab17805367e6a45d2c4682fc9 SDK0.9.2 + virtuelle Linuxmaschine mit eingerichtetem gcc]

[https://drive.google.com/folderview?id=0B5bwBE9A5dBXaExvdDExVFNrUXM&usp=sharing Alternativlink für die virtuelle Maschine + Anleitung/HOWTO für das Setup sowie für das Kompilieren]

=== Firmware updaten ===
Typischerweise wird eine kompilierte Firmware per UART-Bootloader des ESP8266-SoC auf einen Flash-Chip eines ESP8266-Moduls geladen. Von dort startet der ESP8266-SoC anschließend die Firmware.

[http://github.com/themadinventor/esptool Python Tool zum Flashen (von Fredrik Ahlberg)] 
[http://github.com/3s1d/esp_prog Extension zum Tool von Fredrik Ahlberg] 
[http://www.mikrocontroller.net/topic/342240?page=2#3857075 Tool zum Flashen (von Christian Klippel)] 
[http://defcon-cc.dyndns.org/wiki/ESP8266#Update Anleitung, extern] 
[http://www.mikrocontroller.net/topic/342240?page=3#3810559 Anleitung, Forum]

=== Anmerkung ===
Mit dem SDK wird der Mikrocontroller progammiert, der sich direkt auf dem ESP8266-SoC-Chip befindet. Dies ist nicht zu verwechseln mit Programmieranleitungen zur UART-Ansteuerung des ESP8266-SoC (meist mit AT-Firmware) mit einem anderen Mikrocontroller.

==Checkliste bei Problemen mit dem Modul/Compiler/SDK==
Bitte berücksichtige bei der Frage nach Hilfestellung zu Deinem Problem die folgende Checkliste.

'''Bei Problemen mit der AT-Firmware/UART-Ansteuerung mit Mikrocontroller'''
# Was nutzt Du für die Stromversorgung? (Ganz knapp benennen, so dass Rückschlüsse auf Spannung und Stromstärke möglich sind)
# Welche Firmware-Version verwendest Du und von woher hast Du sie?
# Welchen Mikrocontroller verwendest Du?
# Welche Baudrate verwendest Du?
# "Sieht" das Modul den AP, "sieht" der PC das Modul?
# Funktioniert ein Connect?
# Welche AT-Befehlssequenz verwendest Du und was antwortet das Modul?

'''Bei Problemen mit dem SDK/Compiler'''
# Benutzt Du die neuste, offizielle VM? (Diese ist ausgelegt für das neueste SDK)
# Benutzt Du das neueste, offizielle SDK? Welche Version benutzt Du? (Es werden regelmäßig Bugfixes und Erweiterungen eingepflegt)
# Kannst Du die SDK-Beispiele (IoT,AT) entsprechend der offiziellen Anleitung kompilieren, flashen und läuft es?

== SDK Programmers Guide ==
(ggf. später in eigenen Artikel)

''' GPIO Initialisieren, Setzen, Löschen, Lesen: ''' TODO 
''' UART ECHO LOOP: ''' TODO 
''' ADC lesen: ''' TODO 

=== Watchdog und Timer ===
<h4>
In der C Datei in der der Watchdog an/ausgeschaltet werden soll
folgendes definieren:
</h4>
<pre>
extern void ets_wdt_enable(void);
extern void ets_wdt_disable(void);
</pre>
<h4>
Diese beiden Funktionen sind im internen ROM.
Dann eben diese Funktionen entsprechend aufrufen.
</h4>
<h4>
Es gibt auch noch:
</h4>
<pre>
extern void wdt_feed(void);
</pre>
<h4>
Wird diese Funktion aufgerufen wird der Watchdog zurückgesetzt und
startet wieder bei 0.
</h4>

''' Interrupts: ''' TODO 
''' WLAN UDP/TCP ECHO LOOP: ''' TODO 
''' Minimalbeispiel1: GPIO/LED schalten mittels UART: ''' TODO 
''' Minimalbeispiel2: GPIO/LED schalten von einem zweiten Modul aus: ''' TODO 

=== Power-/Sleep-Modes ===
Der Stromverbrauch des ESP8266 ist abhängig von vielen Faktoren, er läßt sich aber durch geschickte Programmierung durchaus deutlich senken. 
So ist es nicht notwendig, dass das WIFI-Modem oder der Mikrocontroller ständig läuft um z.B. eine WLAN-Türklingel zu realisieren. Im "Deep-Sleep" würde der ESP8266 dann nur 10uA verbrauchen, bis er über einen GPI-Interrupt geweckt wird und die Meldung absetzt. 
Zu beachten ist, dass in diesem Moment die WLAN und Netzwerkanmeldung neu startet und hierfür eine gewisse Zeit benötigt wird. 

[http://bbs.espressif.com/viewtopic.php?f=6&t=133 detailierte Übersicht der verschieden Modi und deren Stromverbrauch von Espressif] 

== Links ==
[http://www.esp8266.com/ ESP8266 Community Forum] 
[http://github.com/esp8266 ESP8266 Github mit Wiki und Source-Code Samples] 
[http://defcon-cc.dyndns.org/wiki/ESP8266 ESP8266-Informationen] 

[http://www.mikrocontroller.net/topic/348772 Topic neu im mikrocontroller.net-Forum] 

[http://www.mikrocontroller.net/topic/342240 Topic alt im mikrocontroller.net-Forum] 
[http://www.mikrocontroller.net/topic/342878 Sammelbestellungen im mikrocontroller.net-Forum]

=== Dokumente ===
[https://drive.google.com/folderview?id=0B5bwBE9A5dBXaExvdDExVFNrUXM&usp=sharing Anleitung/HOWTO für das Setup der virtuellen Maschine (SDK) sowie für das Kompilieren] 
[https://nurdspace.nl/ESP8266 Übersetztes Datenblatt] 
[http://www.electrodragon.com/w/Wi07c AT Instructions Set (English)] und [http://www.electrodragon.com/w/Wi07c#First_time_use_guide Anleitung zum Betrieb an einem Arduino (inkl. Code)] 
[http://thomaspfeifer.net/esp8266_wlan_seriell_modul_at_kommandos.htm Beschreibung der AT-Kommandos mit Beispielen] 
[http://www.mikrocontroller.net/attachment/229016/Espressif_IoT_AT____v0.1.5.906.pdf Espressif AT Instruction Set(Chinese)] 
[http://www.seeedstudio.com/document/pdf/ESP8266%20Specifications(Chinese).pdf ESP8266 Specifications(Chinese)] 

===Daten===
[http://bbs.espressif.com/viewforum.php?f=5&sid=3cf7540ab17805367e6a45d2c4682fc9 SDK0.9.2 + virtuelle Linuxmaschine mit eingerichtetem gcc] 
[https://drive.google.com/folderview?id=0B5bwBE9A5dBXaExvdDExVFNrUXM&usp=sharing Alternativlink für die virtuelle Maschine] 
[https://onedrive.live.com/#cid=C4DDF72E6EEA3826&id=C4DDF72E6EEA3826%21631 Dateien (Xplorer+SDK+PDF+etc.)] 
[http://www.mikrocontroller.net/attachment/230185/esp8266_config_v050.exe Config-Tool] 

=== Bezugsquellen ===
[http://www.aliexpress.com/wholesale?SearchText=ESP8266 aliexpress.com] ~ 3€ 
[http://www.banggood.com/?zf=283997 banggood.com] ~ 3.50€ 
[http://www.ebay.de Ebay]
ab 3€ inkl. Versand, Einzelstückpreis: ESP-01/02/03/04/05 
(Suchbegriff: ESP8266, Option Artikelstandort: "Weltweit") 
(10 Stück ab 27 EUR inkl. Versand; Suchbegriff: 10pcs ESP8266) 
ab 3.20€ inkl. Versand, Einzelstückpreis: ESP-07/08/09/11 
[http://www.electrodragon.com/?s=esp8266&post_type=product electrodragon.com] ~ 3.50€ (zzgl. Versand) 
[https://ex-store.de/advanced_search_result.php?keywords=esp8266&x=0&y=0 eX-store.de] (ESP-01,ESP-02, ESP-03,ESP-05,ESP-07) ab 5.49€ (zzgl. Versand) 
[https://www.it-wns.de/themes/suche/index.php?suchekategorie=&sucheallgemein=esp8266 IT-WNS.de] (ESP-01,ESP-03,ESP-07,ESP-12) ab 5.49€ (zzgl. Versand) 
[http://www.seeedstudio.com/depot/WiFi-Serial-Transceiver-Module-w-ESP8266-p-1994.html seeedstudio.com] ~ 5.50€ 
[http://shop.in-circuit.de/index.php?cPath=21 In-Circuit.de] ESP-ADC DIL Modul mit ESP8266EX - made in Germany! professioneller Support, HowTo und Videos ab 500 Stk. je 3.90€, 9.90€ Einzelpreis 

==Anderes==
[http://www.mikrocontroller.net/articles/ESP8266-CPCB PCB für Community-Modul (Vorschlag)]
== Einzelnachweise ==
<references />

--von [[axhieb]]

[[Kategorie:Bauteile]]
[[Kategorie:Funk]]
[[Kategorie:Wlan]]